Live data from Hacker News

New(ish) command line tools

jvns.ca

211–220 of 252 posts

Re: New(ish) command line tools

#211
post #197

Earlier quoted context omitted.

From the PV man page ( https://linux.die.net/man/1/pv ) > A more complicated example using numeric output to feed into the dialog(1) > program for a full-screen progress display: ... > Frequent use of this third form is not recommended as it may cause the programmer to overheat. ^- is that a wisecrack hidden in an otherwise serious man page?

PSA: don't use linux.die.net. It's horribly outdated. This sentence was removed from the man page in pv 1.4.0, released in December 2012.

Agreed, actually enjoy using Arch manpages now:

https://man.archlinux.org/man/community/pv/pv.1.en

Re: New(ish) command line tools

#213
#ifdef NOFLAME

Curiously most of those tools implement things Emacs have since decades. Obligatory #define NOFLAME, I was and to a certain extent a unix guy but after having jumped the ship to Emacs I start seeing in practice many aspects of unix inferiority respect of classic systems, far beyond the Unix Haters Handbook.

File renaming? Dired do that and more than many modern tools, not only in mere editing (wdired-mode) but also in selecting what to edit (marking via regexp, narrowing, manually select files "killing" others etc) in a far more flexible than an unix CLI tool piped to an editor, results are the same of course, easiness it's at another level.

Narrowing/Fuzzy searching? Similarly from Helm to Counsel passing through consult, ido, ...

#endif // NOFLAME

Anyway I still use CLI daily simply because much inhabited to it and for certain things it's quick, and I use some of those tools but the interesting part is not much the tool (dangerously aliased sometimes to overwrite original ones because who remember their name?) but the trend: in the last decade I see a kind of resurgent interest in unix and FLOSS, many that in the past have said "ah, yes, nix are powerful but I need to work no time to learn, ..." in the last decades have started much using GNU/Linux even inside Windows and more and more are accustomed to nix model. Emacs itself seems to have seen a sort of resurgent popularity and that's make me think: did we need so much time to learn?

I mean, we have had the IT revolution from Xerox. Just very few have understood its power and the GAFAM born out of it, starting from the first modern IBM in term of using and ruining Xerox PARC tech to size it's power still giving something to end users. The unix revolution succeed but again for most is a thing of the past and it's successful model is it's failure: they started saying that Xerox desktop model is just too complex and expensive people needs cheap and simpler things, the public agree unix succeed, in just few years they start realizing that no, good iron is needed, GUIs are needed etc and again the big iron era succeed but for a small period of time. PC era wipe it with again cheaper and crappy-er things. PC era succeed and in a moderately short period of time rediscovering of the past desktop model (without knowing it for most) happen, for instance the trend from widgets-based GUIs to document-based ones, the trend toward text-centric works and the recent interest in classic unix witch is actually the most common living vestige of classic model: not really end-user programming, that's Emacs, but at least composability via IPCs in CLI, from IDEs to editors, from DE to WM, perhaps tiling's ones, for some from unix model to Emacs.

Long story short I see a trend that "knowledgeable" people veeeery slowly rediscover classic tech, if that's really a trend and we (society) really need such timeframe to learn... Well... It's a bit sad...

What do you think?

Re: New(ish) command line tools

#214

I thought I’d share a few: - Diffing YAML files: https://github.com/homeport/dyff - Inspecting Docker image layers: https://github.com/wagoodman/dive - Interactive HTTPS proxy: https://mitmproxy.org/

re: Dive -- there's a fork with some updates, https://github.com/jauderho/dive

Re: New(ish) command line tools

#215
post #205

Earlier quoted context omitted.

OMG! I created a GUI tool for this: Simplest File Renamer (Win, Mac, Linux). In my app, you can rename using your favorite code editor, so you have access to all your keyboard shortcuts. https://github.com/whyboris/Simplest-File-Renamer - MIT open source

Except the previous example relies on Rust and the shell, while yours relies on Angular/Electron.

Sorry, by "this" I meant "the same functionality - rename files via text file" :)

Re: New(ish) command line tools

#216

I thought I’d share a few: - Diffing YAML files: https://github.com/homeport/dyff - Inspecting Docker image layers: https://github.com/wagoodman/dive - Interactive HTTPS proxy: https://mitmproxy.org/

re: Dive -- there's a fork with some updates, https://github.com/jauderho/dive

Awesome, thanks for that! It has a bunch of useful stuff merged, but it's still missing the export tree view feature (https://github.com/wagoodman/dive/pull/324), which can be handy.

Re: New(ish) command line tools

#217

I would broadly categorizes these new tools into two categories: 1) those that are adding real value and make things easier, and 2) those that just add bling to existing tools. An example of the former category is ag, an example of the latter is duf. Also, lots of old tools can do more than you think. For example, did you know good old top can display a bar graph of CPU load for each core just like htop? Just press 1…

I like tools that come with nice defaults, so that I don't have to learn tricks like that. To make a somewhat bad analogy, one of the reasons that Ubuntu is so popular vs other distributions is that you have to futz with it less.

Which isn't to say that it wasn't neat to learn that top can do that, but I'm probably still going to continue using htop.

Re: New(ish) command line tools

#218

I could really use a better workflow to refine grep matches. Has anyone made a tool that combines grep (regex search) with fzf (multiple positive/negative patterns)? What I really want is something like: grep pattern1 **/* | grep pattern2 | grep -v exclude_these | grep -v also_exclude The problem is this loses filenames and context lines in the output. I want to apply several positive and negative regexes, and only a…

you probably want awk or perl.

    awk '/pattern1/ && /pattern2/ && !/exclude1|exclude2/ {print FILENAME, $0}' */*

Re: New(ish) command line tools

#219
post #185

Earlier quoted context omitted.

Excuse my ignorance, but what does this command do?

It pipes a list of available git branches into fzf, which lets you filter them by fuzzy string match. When you hit enter, it will take the best matching one and switch to that branch

            _ ._  _ , _ ._
          (_ ' ( `  )_  .__)
        ( (  (    )   `)  ) _)
       (__ (_   (_ . _) _) ,__)
           `~~`\ ' . /`~~`
                ;   ;
                /   \
  _____________/_ __ \_____________

Re: New(ish) command line tools

#220
post #50

I peripatetically dive into "strace" for one-off debugging - is there something more modern I should be doing?

Perf. Extremely powerful. Mostly for profiling and also some scenarios of debugging. Takes a fair bit of getting used to and each debugging session need more setup, compared to just a quick strace. When working with containers it’s even more complicated to setup unfortunately.
Post reply on HN