Why *not* parse `ls` (and what to do instead)

Re:Why *not* parse `ls` (and what to do instead) by Aerbil313 on Tuesday June 25, 2024 @05:42AM (#40786396)

What to do instead: Use Nushell.

I finally started really using my shell after switching to it. I casually write multiple scripts and small functions per day to automate my stuff. I'm writing scripts I'd otherwise write in python in nu. All because the data needs no parsing. I'm not even annotating my data with types even though Nushell supports it because it turns out structured data with inferred types is more than you need day-to-day. I'm not even talking about all the other nice features other shells simply don't have. See this custom command definiton:

  # A greeting command that can greet the caller
  def greet [
    name: string      # The name of the person to greet
    --age (-a): int   # The age of the person
  ] {
    [$name $age]
  }

Here's the auto-generated output when you run `help greet`:

  A greeting command that can greet the caller

  Usage:
    > greet <name> {flags}

  Parameters:
    <name> The name of the person to greet

  Flags:
    -h, --help: Display this help message
    -a, --age <integer>: The age of the person

It's one of the software that only empowers you, immediately, without a single downside. Except the time spent learning it, but that was about a week for me. Bash or fish is there if I ever need it to paste some shell commands.

[ Parent | on HN ]

Re:Why *not* parse `ls` (and what to do instead) by db48x on Tuesday June 25, 2024 @05:56AM (#40786496)

Parsing, or the lack thereof, is not the point. The point is that standard shells already provide all the tools you need for dealing with lists of files. Want to do something for every file? Write this:

    shopt -s nullglob
    for f in *; do
       …
    done

But never this:

    for f in $(ls); do
       …
    done

They look similar, but the latter runs ls to turn the list of files into a string, then has the shell parse the string back into a list. Even if the parsing was done correctly (and it isn’t), this is still extra work. Looping over the glob avoids the extra work.

[ Parent | on HN ]

Re:Why *not* parse `ls` (and what to do instead) by CJefferson on Tuesday June 25, 2024 @08:07AM (#40787489)

How do I replace:

    for f in $(cd subdir; ls); do
       ...
    done

?

[ Parent | on HN ]

Re:Why *not* parse `ls` (and what to do instead) by ykonstant on Tuesday June 25, 2024 @09:39AM (#40788506)

Either

  for f in subdir/*; do
    ...
  done

  ( 
  cd subdir || exit 1
  for f in *; do
    ...
  done
  )

work fine. However, I must insist against using `for` loops in favor of `find`.

[ Parent | on HN ]

Re:Why *not* parse `ls` (and what to do instead) by Aerbil313 on Tuesday June 25, 2024 @06:14AM (#40786602)

I have to say this is very unintuitive. In Nushell, you'd do:

  ls | each { ... }

Another examples I don't need to explain, which would be far harder in stringly typed shells:

  ls | where type == file and size <= 5MiB | sort-by size | reverse | first 10

  ps | where cpu > 10 and mem > 1GB | kill $in.pid

It's immediately obvious what you need to do when you can easily visualize your data:

  > ls
  ╭────┬───────────────────────┬──────┬───────────┬─────────────╮
  │ #  │         name          │ type │   size    │  modified   │
  ├────┼───────────────────────┼──────┼───────────┼─────────────┤
  │  0 │ 404.html              │ file │     429 B │ 3 days ago  │
  │  1 │ CONTRIBUTING.md       │ file │     955 B │ 8 mins ago  │
  │  2 │ Gemfile               │ file │   1.1 KiB │ 3 days ago  │
  │  3 │ Gemfile.lock          │ file │   6.9 KiB │ 3 days ago  │
  │  4 │ LICENSE               │ file │   1.1 KiB │ 3 days ago  │
  │  5 │ README.md             │ file │     213 B │ 3 days ago  │
  ...

[ Parent | on HN ]

Re:Why *not* parse `ls` (and what to do instead) by db48x on Tuesday June 25, 2024 @06:18AM (#40786622)

I didn’t say that nushell is bad, I said that it’s not relevant to the discussion. nushell provides typed data in pipelines, which is cool. But standard shells already have typed data for this particular use case, thus parsing untyped data is unnecessary. Of course it would be nice if that typed data could be used in a pipeline, but everything had to start somewhere.

[ Parent | on HN ]

Re:Why *not* parse `ls` (and what to do instead) by acureau on Tuesday June 25, 2024 @09:20AM (#40788276)

Who are you to decide what's relevant to the discussion? It's very clearly on topic. I had never heard of nushell and I'm glad it was mentioned

[ Parent | on HN ]