Atleast follow standard practice in your example
Fails : enumerate -f '.txt' -- 'wc -l {}'
For all use cases
Correct : enumerate -f '.txt' -- 'wc -l -- {}'
I wrote an bash enumerator because I was sick of xargs
71–80 of 202 posts
Re: I wrote an bash enumerator because I was sick of xargs
#72calling it 'bashnumerate' and then have the command be 'enumerate' is confusing. find one and stick with it.
Re: I wrote an bash enumerator because I was sick of xargs
#73I wanted something simpler — one consistent way to iterate over anything. That's not actually simpler though. Simple is removing everything unnecessary. You took commands which could already do what you wanted, and added an extra program which calls them in specific ways. This will add bugs and maintenance headaches, not be portable, etc. This is added complexity. The reason you made this script is not because you wa…
Hm. Underrated comment
Re: I wrote an bash enumerator because I was sick of xargs
#74> Or maybe you pipe into xargs and pray your filenames don’t have spaces… Most of this, if not all, is fixable by adding a `export IFS=$'\n'` to your bashrc. I'm not trying to disregard your project, just point out something that took me years to learn and I currently use extensively to solve this very problem. Perhaps you didn't know about it until now... :)
Another trick that took me years to learn is to use `xargs -I` to split the results into "items"
For example
`ps aux | grep process-name | grep -v grep | awk '{ print $2 }' | xargs -Ieach kill -9 each`
Re: I wrote an bash enumerator because I was sick of xargs
#7555 comments and nobody mentioned the incorrect English in the title?
I'm glad you here to save us. What would we do without you?
Re: I wrote an bash enumerator because I was sick of xargs
#76Earlier quoted context omitted.
Bash while loops are pretty readable and the above would be a nice to iterate over lines if it wasn't for that gnarly pipe, which is a common source of errors in this construct. Remember that a pipe starts a new shell. So: grep stuff file.txt | while read key value ; do [ "$key" = "target" ] && found="$value" ; done where you might expect $found to end up with the value for the line that has "target" in the first col…
> and isn't compatible is that a GNU v POSIX type of compatibility issue?
bash vs. POSIX sh (or some other shells)
zsh should be bash compatible on this AFAIR
Re: I wrote an bash enumerator because I was sick of xargs
#77On the topic of xargs replacements, I love gnu parallel. The --dry-run flag of parallel made me confident to do more batch processing than I ever did with xargs. Parallel has an option for almost everything, it's almost too much. But I have shopped around for alternatives. The creator Ole Tange maintains a painstakingly long article of the alternatives and their differences. [0] The gnu parallel book and reading mate…
Oh man, parallel is awful. I have to rant about this because I literally tried it again today morning. Every single damn time I try parallel and decide to give it another chance, something ends up not working or causing a problem. I can never get it to just do what I want and get out of the way. Today I foolishly thought maybe I was the one who was holding it wrong every single time in the past, so I copy pasted anot…
This is pretty funny. You almost had me until the Perl part. Not going to get baited this time!
Re: I wrote an bash enumerator because I was sick of xargs
#78Not sure I see the point of this. Remembering a bunch of options on one tool is no better than a bunch of tools/constructs? Especially if the latter are useful elsewhere. And it can't be used for scripts unless you start shipping it alongside, which… nah. Just go with foo | while read X; do bar "$X"; done
Depending on the actual command, this can be far slower and less efficient than xargs. You're creating a separate process for each invocation of bar when a lot of commands will take many targets for a single invocation. Try this with find and grep vs xargs. There's a big difference.
3 reasons against that:
* in a lot of cases the performance just doesn't matter
* xargs gets you the spaces in filenames landmine
* some commands don't even support multiple target filename arguments
For scripts in long term use, yeah, sure, figure out xargs maybe. Any other situation with a "| while read" solution, especially on an interactive session, is an oddball and simplicity wins.
Re: I wrote an bash enumerator because I was sick of xargs
#79Not sure I see the point of this. Remembering a bunch of options on one tool is no better than a bunch of tools/constructs? Especially if the latter are useful elsewhere. And it can't be used for scripts unless you start shipping it alongside, which… nah. Just go with foo | while read X; do bar "$X"; done
Bash while loops are pretty readable and the above would be a nice to iterate over lines if it wasn't for that gnarly pipe, which is a common source of errors in this construct. Remember that a pipe starts a new shell. So: grep stuff file.txt | while read key value ; do [ "$key" = "target" ] && found="$value" ; done where you might expect $found to end up with the value for the line that has "target" in the first col…
You can put the "< <( foo )" before the "while" btw, for pipe-like ordering of things. All redirections can be anywhere on the command line.
Re: I wrote an bash enumerator because I was sick of xargs
#80Earlier quoted context omitted.
Oh man, parallel is awful. I have to rant about this because I literally tried it again today morning. Every single damn time I try parallel and decide to give it another chance, something ends up not working or causing a problem. I can never get it to just do what I want and get out of the way. Today I foolishly thought maybe I was the one who was holding it wrong every single time in the past, so I copy pasted anot…
> the app just hung there trying to figure out how long its command line can be? That's common on linux. Many tools read from stdin if a file path isn't given: cat, xargs, base64, cksum, etc. The citation thing is a little silly, I'll give you that one.
> That's common on linux. Many tools read from stdin if a file path isn't given: cat, xargs, base64, cksum, etc.
No. I did pipe to stdin. It's not my first time using Linux...
Here's a command line I ran right now, and the output I see:
$ echo "http://www.example.com" | parallel -k -j 8 curl -s "{}"
Academic tradition requires you to cite works you base your article on.
[...more nonsense...]
To silence this citation notice: run 'parallel --citation' once.
parallel: Warning: Finding the maximal command line length. This may take up to 1 minute.
So I Ctrl+C. And then the parent perl process gets killed, but the child apparently keeps running.
I press Ctrl+D to exit the terminal, and then:
$ # (Ctrl+D pressed)
logout
xargs Just Works without any of this nonsense, yet somehow I'm the one holding GNU parallel wrong?