[giov4]

I lol'd, but do you think this is valid?

https://github.com/wallach-game/bashumerate/pull/1/files

to me looks like a right solution, even if I was also tired of writing for loops by hand usually

[inigyou]

The main reason to use xargs is to split up argument lists before they exceed the limit.

[Dibby053]

Some of these are wrong, as standard shell globs don't traverse directories. For instance the first example should be:

    ls **/*.sh

I think that would work in Bash just as well as using find.

But yeah, even in POSIX it feels redundant when we already have find, seq, grep and whatnot.

[js2]

I thought I knew every nook and cranny of bash, but somehow never noticed the globstar option added in bash 4.0.

https://www.linuxjournal.com/content/globstar-new-bash-globb...

https://www.gnu.org/software/bash/manual/bash.html#Pattern-M...

[wongarsu]

I frequently have cases where `ls **/*.png` fails because the argument list is too long. Just happened yesterday with an rm I wanted to run.

Find works, but the syntax is arcane. Not bad, but unlike any other common cli tool, which makes it more difficult to remember if you haven't needed it in a while

[jimmaswell]

> Find works, but the syntax is arcane.

fd is a lifesaver: https://github.com/sharkdp/fd

[giov4]

I agree and I usually ended-up combining find reliability with other commands to obtain what I needed without big issues or too much looping syntax effort.

Regarding remembering the find syntax I think its being arcane is what it made for me more easy to remember :) I now have a unique brain area dedicated to remember only that.

[Grimeton]

Newer finds have a -delete option. Dunno if that's standard or some GNU addition, but it's there.

[IsTom]

To be pendantic

    ls -- **/*.sh

Otherwise it will fail if you've got a file named e.g. --help

[ahoef]

So, it's essentially argument injection?

I dislike these tools so much, because you need to know all these corner-cases and I don't.

[IsTom]

Yeah, this happens broadly in shell with globbing. It's a bit ridiculous.

[westurner]

But `ls -print0` is not an option;

  set -x
  mkdir test; cd "$_"
  touch "test "$'\n'"12.txt"
  ls
  for name in `ls`; do echo "$name"; done
  find
  find . -exec echo {} \;
  find . -print0
  find . -print0 | xargs -n 1 -0 echo
  #
  find . -print0 | el -0 -v -x echo
  find . -print0 | el -0 -v -x echo "{0} #"
  find . -print0 | el -0 -v -x echo '"{0}" #'
  find . -print0 | el -0 -x sh -x -c 'echo "{0} #"'
  

Though, I just realized that this doesn't work yet either:

  find . -print0 | el -0 -x -- sh -c 'set -x: echo "{0} #"'
  

westurner/dotfiles/scripts/el: "edit lines" https://github.com/westurner/dotfiles/blob/master/scripts/el...

`el -v/--verbose` is useful because it prints each input; though, I might not have written `el` if I had been aware of `xargs -n/--max-args=1`

[tolciho]

  for name in `ls`; do echo "$name"; done

is an unportable and expensive way to write

  for name in *; do printf '%s\n' "$name"; done

but you could also just

  printf '%s\n' *

[giov4]

On a second thought I think that the effort in trying to find a shell uncomfortability problem and trying to solve it with a "wrapped workaround" still represents positive effort and should be supported and fostered without jumping directly in 90's like rtfm mode.

especially in the case of a younger profile, learning and putting dev effort, even if vibed or redundant, its still effort and a learning activity!

https://github.com/wallach-game

so I support this even if the result and problem solving can be less significant

[Dibby053]

It's possible the tool is useless and a consequence of not reading the manual, but it could just be the tool is nice but the examples are too simplistic.

In any case, toxicity aside, publishing a command line project and having someone dismiss the examples with shell oneliners is also a valuable lesson, and I don't think it will make him a worse developer.

[giov4]

that's what I also thought when I saw the pull request, that it could be a useful lecture.

But again the usefulness of the final tool should not compromise appreciation of effort and learning.

Unless the tool targets, claims or pretends to be the best, final and universal solution to such problem.

I believe it isn't, I will still fall back to my bash memories, I will not need, install and use this tool, I will not need, install or use custom shells. The effort wasted in re-aligning my brain to a tool change would superseed instantly the few second effort needed to reach the needed bash one-liner.

Also, didn't you also feel good and amazed when completing a very long and nested working one-liner? wasn't that orgasmic? :D