This gives an (artificial) example of the power of GNU Parallel over xargs: https://unix.stackexchange.com/questions/405552/using-xargs-...
16 karma · joined May 8, 2018
How so? GNU Parallel only outputs the notice if stderr is a terminal. I think you did not try this. Am I right about that?
It is litteraly the 3rd point in https://git.savannah.gnu.org/cgit/parallel.git/tree/doc/cita...
Did you try any of the other situations? Or are you simply speculating that this might cause problems without actually testing?
Speed wise they are comparable to GNU Parallel. So the argument for Rust could be speed.
The argument against Rust could be backwards compatibility: How would you do the {= perl expr =} thing? Will it run on the current targets (CentOS 3.9 according to https://www.gnu.org/software/parallel/parallel_design.html#O...)? Will it run on systems for which you as a consultant do not have access to a Rust compiler for?
$ seq 0 5 100000 | parallel touch {}.txt
Or you you really want the infinite loop:
$ yes | parallel touch '{= $_=seq()*5 =}'.txt
'$' must be quoted
$ loop --count-by 5 -- touch '$'COUNT.txt
parallel --slf input_file_here -j16 --nonall echo 'Matrix has you'Run 'parallel --citation' ONCE and have the notice silenced.
I never understood the complaint: Is it because people do not _read_ the message?
It used to be an issue that non-free UNIXes did not include a C-compiler by default, and then C would really not help. I am not sure if that is the case anymore.
I often create bash functions to avoid that shit, and then call the bash functions from GNU Parallel instead.
It is definitely not something I would dare to run in production.
parallel sh -c "echo hi; sleep 2; echo bye" -- 1 2 3
parallel echo hi";" sleep 2";" echo bye ::: 1 2 3
parallel -j 3 ufraw -o processed -- *.NEF
parallel -j 3 ufraw -o processed ::: *.NEF
parallel -j 3 -- ls df "echo hi"
parallel -j 3 ::: ls df "echo hi"
If you have a hard time getting it to work and remember how, then it is likely that the fundamentals of GNU Parallel are not clear to you. Chapter 2 ("Learn GNU Parallel in 15 minutes") of the book should take care of that.
> a better interface
That is often a tough one. I, for one, like emacs' interface. Others despise it. So when you write 'better interface' I think it will be helpful if you were more specific.
I see loads of commercials for buying iPhones. I do not see a lot of commercials for citing GNU Parallel.
If I have to make a citation, it will cost me no money, but one line of text if I write an article. If I have to buy an iPhone, it will cost me many hours of work.
To me the two things are not even close to be similar.
But I can find one similar aspect: No one forces you to use an iPhone.
To me the dialog box is actually worse, because the program often blocks until you close the dialog box (not 100% sure if that is the case with Firefox).
With GNU Parallel you run 'parallel --citation' once, and you are done. We are talking an effort of 15 seconds or less.
When I install a library I often have to run the install command and it often takes longer than 15 seconds.
Finally, I would like to understand why you do not just use another utility? Would that not solve your issue?
https://lists.gnu.org/archive/html/parallel/2013-11/msg00006...
"In other words: It is preferable having fewer users, who all know they should cite, over having many users, who do not know they should cite.
If the goal had been to get more users, then the license would have been public domain.
...
The citation notice is about (indirect) funding - nothing else."
Does that fit with your assumption that "the GNU Parallel author(s) want/wants people to use and contribute to it"?
I usually just run --citation once on a new system, and never see the notice again, and I have never had the notice cause any problems as it only shows if the output is to the screen.