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

211–220 of 280 posts

Re: CLI: Improved

#211

Post by needlepont »

burntsushi wrote: post #55
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…

ripgrep definitely goes against the Unix philosophy. This is intentional. The Unix philosophy is a means to an end, and not an end unto itself. The key way that ripgrep violates the Unix philosophy is that it couples the filtering of what to search with the act of searching. You hit the nail on the head with styling, because the output of ripgrep is itself the thing that prevents composability. However, from my own o…

I've never understood complaints like this. If you are proficient in the unix environment any sort of gymnastics can be handled via generation of some 'object' from plaintext and command generation on the fly. find $PATH -name '.c' -exec grep -l socket {} \; | awk ' {printf "mv %s %s\n",$0,sprintf("%s.old",$0)}' find $PATH -name '.c' -exec grep -l socket {} \; | awk ' BEGIN {n=0} {printf "{\"items\": \%s",sprintf("[\"%d\",\"%s\"]}\n",n++,$0)}'

If you aren't proficient or have an aesthetic or religious aversion to unix userland and traditional tools you'll play some other game I guess. Reinventing the wheel without understanding the model and power is a next-gen game. I don't have time for it.

Re: CLI: Improved

#212

Post by AnIdiotOnTheNet »

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) {…

First of all, the two examples you present do not do the same thing. The Powershell version preserves paths and excludes more patterns than your find | xargs example. The right way to do this is to just use robocopy.

This example has targeted a very specific deficiency in the way Copy-Item works. I could similarly point out that the following Powershell command would be much more difficult in standard unix tooling:

  Get-WMIObject -Computer $remote -Class Win32_Product | Where-Object { $_.name -like "7-Zip*" } | select Version
Which gets the version(s) of 7-Zip installed on a remote machine.

Re: CLI: Improved

#213

Post by Aaronepower »

steveklabnik wrote: post #34
orf wrote: post #29

Is anyone else impressed with the quality (and speed!) of some of the tools written in Rust? I'm an avid user of fd and bat, the former being ridiculously fast. Often I find something on github, I'm impressed by the quality of the documentation, features, UI etc, then lo and behold it's written in Rust. Another one potentially for this list is tokei[1] I was trying to count the code in our repos at work and used the…

IIRC, loc (in rust) might be even faster than tokei at times? I always forget, and I’m sure I saw an old benchmark... We have a whole working group this year focused on making the experience of writing CLIs awesome, so hopefully we’ll see even more great tools in the future!

Well luckily I recently published a new comparison benchmark[0]. :)

The TL;DR is that loc is faster by a few hundred milliseconds depending on repository size, but as cgag mentions doesn't have comment in string detection so can be quite off in its metrics, for example on the Rust repo Tokei says it has 643,754 lines of code where as loc says it's 635,849.

[0]: https://github.com/Aaronepower/tokei/blob/master/COMPARISON....

Re: CLI: Improved

#214

Post by Sean1708 »

l0b0 wrote: post #62
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…

"One thing" has never been very well defined - basically every common Linux shell tool could be said to do more than one thing. GNU `grep` supports four different pattern styles (fixed strings, basic regex, extended regex and Perl regex), has lots of options for output formatting (counting, line numbers, whether to display file names, etc.) and has a bunch of rarely-used (but useful!) options for various corner cases…

> Even GNU `cat`, the canonical "do one thing" tool, has several formatting options.

Huh, TIL. It's just never occurred to me to even bother checking the help for cat.

  $ cat --help
  Usage: cat [OPTION]... [FILE]...
  Concatenate FILE(s) to standard output.
  
  With no FILE, or when FILE is -, read standard input.
  
    -A, --show-all           equivalent to -vET
    -b, --number-nonblank    number nonempty output lines, overrides -n
    -e                       equivalent to -vE
    -E, --show-ends          display $ at end of each line
    -n, --number             number all output lines
    -s, --squeeze-blank      suppress repeated empty output lines
    -t                       equivalent to -vT
    -T, --show-tabs          display TAB characters as ^I
    -u                       (ignored)
    -v, --show-nonprinting   use ^ and M- notation, except for LFD and TAB
        --help     display this help and exit
        --version  output version information and exit
  
  Examples:
    cat f - g  Output f's contents, then standard input, then g's contents.
    cat        Copy standard input to standard output.
  
  GNU coreutils online help: 
  Full documentation at: 
  or available locally via: info '(coreutils) cat invocation'

Re: CLI: Improved

#215

Post by Sean1708 »

vitorbaptistaa wrote: post #133
bradknowles wrote: post #92

Earlier quoted context omitted.

The thing I would like to see with grep is to have it optionally give me a 0 return code if it doesn't find anything. I know why the authors chose to use a non-zero return code as the default, but when I'm using grep deep in a pipeline and doing my own checking of the results to see if nothing was found, I don't need grep bombing out the whole pipeline with a non-zero return code. The alternative of being forced to u…

I'm not in my computer now, but doesn't "grep -v" solves your issue? If I remember correctly, it inverts the query, so it would return 0 if there wasn't a match.

No, -v will return 0 unless every line matches:

  $ cat > foo
  here's
  some
  random
  text
  $ grep -v some foo; echo $?
  here's
  random
  text
  0
  $ grep -v bar foo; echo $?
  here's
  some
  random
  text
  0
  $ grep -vE "(here's|some|random|text)" foo; echo $?
  1

Re: CLI: Improved

#216

Post by vram22 »

jaco8 wrote: post #128
vram22 wrote: post #115

Earlier quoted context omitted.

FreePascal has been around for a long time and supports CLI programming. Maybe not very much support in the basic language and stdlib, but the essentials are there (CLI arg handling and file I/O). Third-party libraries may have more and you can always write your own. Both speed and size of binaries are good. I had compiled some simple CLI programs and they were under 100K, maybe under 50K. It's also supposed to be qu…

You would be very, very pleased with Nim. https://nim-lang.org/

Thanks. I had seen some HN threads on it, but had not really checked it out. Will do so.

Re: CLI: Improved

#217

Post by burntsushi »

needlepont wrote: post #211
burntsushi wrote: post #55

Earlier quoted context omitted.

ripgrep definitely goes against the Unix philosophy. This is intentional. The Unix philosophy is a means to an end, and not an end unto itself. The key way that ripgrep violates the Unix philosophy is that it couples the filtering of what to search with the act of searching. You hit the nail on the head with styling, because the output of ripgrep is itself the thing that prevents composability. However, from my own o…

I've never understood complaints like this. If you are proficient in the unix environment any sort of gymnastics can be handled via generation of some 'object' from plaintext and command generation on the fly. find $PATH -name ' .c' -exec grep -l socket {} \; | awk ' {printf "mv %s %s\n",$0,sprintf("%s.old",$0)}' find $PATH -name ' .c' -exec grep -l socket {} \; | awk ' BEGIN {n=0} {printf "{\"items\": \%s",sprintf("…

Just because I built ripgrep doesn't mean I've reinvented a wheel without understanding the existing model/power, so your criticism feels a bit disingenuous to me.

To be clear, with the current release of ripgrep, you cannot create structured objects from its output as easily as you might think. I get that it's fun to show how to do it with long shell pipelines for simple cases, but the current release of ripgrep would actually require you to parse color escape sequences in order to find all of the match boundaries in each line. This is what tools like VS Code do, for example. The --json output format rectifies that. There are other solutions that might be closer to the text format, but they're just more contortions on the line oriented output format that aren't clearly useful for human consumption, and it's much simpler to just give people what they want: JSON.

Re: CLI: Improved

#218

Post by hultner »

andrepd wrote: post #69

Re: bat > cat Cat is just a tool to dump files to stdout and maybe concatenate them. If you want paging, syntax highlighting, etc, you probably want a tool to replace `less`, not `cat`.

view is also perfectly good, it's vim's pager.

Re: CLI: Improved

#219

Post by kokey »

patja wrote: post #14

"I'm not sure many web developers can get away without visiting the command line." IIS has significant market share. I'll bet most web developers who deploy on it get away without having to use the command line interface very often if at all. https://news.netcraft.com/archives/2018/08/24/august-2018-we...

That says 6.26% of active sites and that's lower than last year.

Re: CLI: Improved

#220

Post by qalmakka »

nextos wrote: post #28

GNU Parallel is the first thing I usually install on top of a standard Unix userland. It's almost a superset of xargs, with many interesting features. It depends on perl, though. htop is also pretty much a great replacement for top. And ripgrep a great replacement for the find | xargs grep pattern. Aside from that, I'm pretty content with the Unix userland. It's remarkable how well tools have aged, thanks to being co…

Is the Perl dependency actually relevant? I've never seen a Linux distro that doesn't install Perl 5 by default, and it's also installed by default on macOS and OpenBSD. The other BSDs all have Perl in their ports, and you almost always end up installing it anyway due to the sheer amount of stuff that depends on it.
Post reply on HN