#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-m…
> 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? Resurgence? Google tells me otherwise... https://imgur.com/a/urcePZq
New(ish) command line tools
241–250 of 252 posts
Re: New(ish) command line tools
#242broot completely changed the way I navigate directories on the CLI over the past year. I was an 'ls' purist before, I've tried various CLI file managers in the past and they all felt like they added too much friction, with the one exception of nnn which I briefly used before finding broot, which just feels really fluid and natural.
Re: New(ish) command line tools
#243Earlier quoted context omitted.
This is amazing! Is it possible to do the following somehow? - automatically have this for any command that outputs more than 10 lines? - automatically exit when the main command (for example a dev server) exits? - print the output of the main command to stdout after this is done?
> automatically have this for any command that outputs more than 10 lines? Probably not. The output of a command typically goes directly to the terminal and does not pass through the shell, so the shell has no idea how many lines there are. You could write a shell where that's not the case, but that would have issues with interactive things - what happens if you run e.g. vim or htop in that context? You can pipe to `…
``` -F ........ --quit-if-one-screen Quit if entire file fits on first screen. ```
Re: New(ish) command line tools
#244None of the "replacements" interest me. When I try the "new" ones I cannot get interested in them either. When trying new programs I am looking for whether a program can do something essential that I cannot do myself, e.g., with shell scripts. However I am beginning to think another reason is that these "new" utilities are consitently too complicated, e.g., too many options. It often seems as if the authors are tryin…
Classic UNIX tools are god awful to use in terms of quality of life. Newer tools are far more ergonomically pleasing. The real reason people are hesitant to use new tools is that there is a massive switching cost for most of them.
Re: New(ish) command line tools
#245Earlier 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.
Re: New(ish) command line tools
#246Earlier quoted context omitted.
> I recently found out about mdp too, a way to display markdown in the terminal as slides. > https://github.com/visit1985/mdp I use pandoc to convert markdown to powerpoint decks, it's a great workflow as you can preview and tweak the content and then apply the firm theme before the presentation.
Do you mean actual PowerPoint or just creating a (presumably HTML based) presentation?
pandoc -f markdown input.md -o output.pptx
Re: New(ish) command line tools
#247Re: New(ish) command line tools
#248Earlier quoted context omitted.
Given that I'm guaranteed to forget that I have this thing installed if I would install it, I'm just going to steal the idea and try to remember to use my editor instead of an ugly shell loop next time I want to rename many files. There's only a small difference, really, between transforming `1.txt 2.txt 3.txt` to `file1.md file2.md file3.md` and transforming to `mv 1.txt file1.md; mv 2.txt file2.md; mv 3.txt file3.m…
You likely already know this, but just a reminder/tip that bash and zsh will let you edit the current command you’re entering in your editor of choice if you press ctrl+x ctrl+e (without releasing ctrl between). (Note if you’re using zsh without ohmyzsh, you’ll have to enable this manually [1]) [1]: https://nuclearsquid.com/writings/edit-long-commands/
Re: New(ish) command line tools
#249Earlier quoted context omitted.
How does nnn compare to ranger https://github.com/ranger/ranger ?
ranger is fancier (both visually and in terms of configurability), but nnn is significantly faster in my experience. I kept putting off looking into ranger's rifle capabilities and Python scripting, but after having it crash on me a couple times - in a directory with many hundreds of files, to be fair - I tried nnn. The speed and simplicity made me switch over entirely, because it has just the right amount of feature…
Re: New(ish) command line tools
#250I really like the approach of pipe-rename ( https://github.com/marcusbuffett/pipe-rename ) for renaming many files. It's especially convenient for people who can efficiently edit many lines in their favorite text editor (so everybody here, I guess). Main problem: you maybe don't do this kind of operation frequently enough to remember how it's called or how you aliased it.
ls | % {rename-item $_ -newname $('myfile_' + ($_.BaseName -replace '\D') + '.md' )} No need to remember anything.