Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CLI: Improved

remysharp.com

Post reply on HN
Print view View original

171–180 of 280 posts

Re: CLI: Improved

#171

Post by h1d »

pjmlp wrote: post #162
h1d wrote: post #146

Earlier quoted context omitted.

Used PowerShell to code a small script and simply making md5 of a string is enough to make you feel nuts. The UNIX style. echo -n 'string' | md5 Compared to that obvious command, this is utter madness. You can't write a single thing without googling. $string = "string" $md5 = new-object -TypeName System.Security.Cryptography.MD5CryptoServiceProvider $utf8 = new-object -TypeName System.Text.UTF8Encoding $hash = [Syste…

Of course, because someone wrote a md5 executable for you to call. You can do the same on PowerShell and write a pipeline just the same way.

You're right that a shell alone can't calculate md5 but a separate md5 binary does it for you, but the question still stands when the common answer on the internet seems to be to write that cryptic code as that's probably the easiest way provided on PowerShell.

The best alternative I could find is some community maintained PowerShell extension (with just 177 GitHub stars now), which is far better but the lack of interest in making PowerShell act more straightforward is weird.

"string" | Get-Hash -Algorithm MD5

(https://github.com/Pscx/Pscx)

Still feels funny to read the GGP's comment.

> 70s-era tooling is inferior in some way to something designed with 30 years of hindsight

Re: CLI: Improved

#172

Post by h1d »

flukus wrote: post #167
h1d wrote: post #146

Earlier quoted context omitted.

Used PowerShell to code a small script and simply making md5 of a string is enough to make you feel nuts. The UNIX style. echo -n 'string' | md5 Compared to that obvious command, this is utter madness. You can't write a single thing without googling. $string = "string" $md5 = new-object -TypeName System.Security.Cryptography.MD5CryptoServiceProvider $utf8 = new-object -TypeName System.Text.UTF8Encoding $hash = [Syste…

A while ago I was trying to copy a bunch of files and couldn't believe the powershell abominations I found: https://techblog.dorogin.com/powershell-how-to-recursively-c... $exclude = @("main.js") $excludeMatch = @("app") Get-ChildItem -Path $from -Recurse -Exclude $exclude | where { $excludeMatch -eq $null -or $_.FullName.Replace($from, "") -notmatch $excludeMatch } | Copy-Item -Destination { if ($_.PSIsContainer) {…

  rsync -a --exclude=app/ --exclude=main.js sourceFolder/ destFolder/
Thank you, thank you unix tools.

Re: CLI: Improved

#173

Post by h1d »

fredsted wrote: post #168

I like these kinds of articles, but it's rare I need that many CLI tools on my MacBook. I interact with hundreds of servers on a day-to-day basis, and I don't want to go around installing random tools on my servers. But I guess it's an idea for some tools to add to my Ansible server provisioning script :-)

I always update my Ansible script when I find something worthwhile.

Besides, why not just make a $HOME/bin/ and throw your new stuff in there?

Re: CLI: Improved

#174

Post by h1d »

demosito666 wrote: post #56
barbegal wrote: post #51

I feel like these tools very much go against the Unix philosophy of "Write programs that do one thing and do it well". They try to do the pretty user interface and the underlying operation in a single tool. I prefer PowerShell in this respect where the output of each command is not text streams (as in the Unix world) but objects which can be operated on in a more object oriented way. You spend less time thinking abou…

This is correct. The thing is, powershell is not for humans. It is purposed more towards configuration and system scipting, and thus should be compared to something like ansible. Using it as a shell is counter-productive unless you have very specific mindset. Unix shell, on the other hand, is a trade-off: it offers you options to process and automate and reasonable convenience when working interactively. None of thos…

Who is going to write "configuration and system scipting" if it isn't for humans? Ansible playbook reads very easily to humans.

Re: CLI: Improved

#175

Post by TeMPOraL »

h1d wrote: post #171
pjmlp wrote: post #162

Earlier quoted context omitted.

Of course, because someone wrote a md5 executable for you to call. You can do the same on PowerShell and write a pipeline just the same way.

You're right that a shell alone can't calculate md5 but a separate md5 binary does it for you, but the question still stands when the common answer on the internet seems to be to write that cryptic code as that's probably the easiest way provided on PowerShell. The best alternative I could find is some community maintained PowerShell extension (with just 177 GitHub stars now), which is far better but the lack of inte…

Still, all that stops PS from being a better shell in linuxland is some people writing PS-equivalents of all the small executables that ship with your linux distribution.

Re: CLI: Improved

#176

Post by TeMPOraL »

JoshMnem wrote: post #130
nextos wrote: post #96

Earlier quoted context omitted.

Notmuch, which is IMHO superb and totally underrated. I like it a lot due to its clever architecture. It never ever touches your email. It operates on a separate tag database. Then, it's the task of a backend to translate tag changes into maildir actions before and after syncing email. Keeping tag to actions decoupled from the GUI is extremely clever, because it allows implementing basically any email workflow you ca…

Thanks, I'm in the process of migrating from Thunderbird to mutt/neomutt and am wondering if emacs might have advantages. I already use Emacs for Org Mode. I'm also looking for a scriptable, text-based RSS reader: https://community.codeselfstudy.com/t/text-based-rss-atom-fe...

> am wondering if emacs might have advantages

Fresh mu/mu4e user here. The advantages over mutt/neomutt are that your e-mail now becomes the part of the same consistent UX of Emacs, and then every improvement to any of your workflows in Emacs is automatically inherited by your e-mail workflow. This depends on how much you like customizing Emacs and/or writing Emacs Lisp to solve your problems. Some practical examples include:

- org-mu4e & org-notmuch will let you link directly to your e-mail messages from your org-mode files; potentially useful if you're using org-capture to quickly add TODOs and notes.

- it's trivial to add any kind of template responses, template subresponses, etc.

- you can make Emacs automatically do things in response to particular e-mails, or you can compose/send e-mails directly from any elisp code

Emacs is a fully programmable environment with lots of existing software packages and the best interoperability story I've ever seen.

Re: CLI: Improved

#178

Post by h1d »

thibran wrote: post #10
hs86 wrote: post #4

With tools like these or ripgrep it is useful to know whether the authors try to replace the old tool or not. This is usually stated somewhere in their readme or faq. If they choose to approach some problems with different semantics, I would not recommend to alias the new tool over the old one. Just treat it as a like a separate tool and in most cases their new names are as comfortable to type as the 'legacy' tool's.…

If you like exa, maybe you like my modifications about hiding the time output optionally when using '--long', too. https://github.com/thibran/exa/tree/time_style_hide Example output of 'exa -l --time-style=hide': drwxr-xr-x - foo Desktop drwxr-xr-x - foo Documents drwxr-xr-x - foo Downloads drwxr-xr-x - foo Music drwxr-xr-x - foo Pictures drwxr-xr-x - foo src drwxr-xr-x - foo Videos

For just listing without additional info, I'm good with just the file tree. With '-l' it can show bunch of stuff.

  $ l (exa --tree --level 1)
https://i.imgur.com/RxppCIt.png

  $ l2  (exa --tree --level 2)
https://i.imgur.com/Mba79iz.png

Re: CLI: Improved

#179

Post by h1d »

joombaga wrote: post #61
hk__2 wrote: post #24

Earlier quoted context omitted.

Of course, but its primary purpose (combining files) differs from its primary usage (showing a file’s content).

The primary usage us just a special case of its primary purpose. You're concatenating the file with nothing.

I never concatenated a file using cat.

Re: CLI: Improved

#180

Post by h1d »

badminton1 wrote: post #155

- ranger (and the ranger-cd script) are pretty useful to explore folders in the terminal. https://github.com/ranger/ranger - percol and ripgrep as alternatives to grep - tig as TUI for git - kakoune as alternative to vim

I like vifm over ranger. Simple dual pane with vi key binding.
Post reply on HN