new | show | ask | jobs Github

nvme0n1p1 16 hours ago

> 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.

▲ 15 hours ago | parent | next [-]

[deleted]

▲ dataflow 10 hours ago | parent | prev [-]

> 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 wait a few seconds... until I get fed up and look at my process list, and I see perl is just... seemingly sitting there, doing seemingly absolutely nothing. I'm not going to waste a whole minute of my life waiting for this; I see no reason competently written software should take that long just to accomplish such a simple task where nothing is remotely close to reaching any limits.

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

...it just sits there waiting. Ctrl+C and Ctrl+\ do nothing. I have to kill the lingering perl process manually.

xargs Just Works without any of this nonsense, yet somehow I'm the one holding GNU parallel wrong?

▲ darrenf 10 hours ago | parent | next [-]

> parallel: Warning: Finding the maximal command line length. This may take up to 1 minute.

> So I wait a few seconds [snip]

This warning is only ever printed if running in Cygwin, not Linux or macOS or elsewhere. Cygwin is notoriously slow.

    # This is slow on Cygwin, so give Cygwin users a warning
    if($^O eq "cygwin" or $^O eq "msys") {
    ::warning("Finding the maximal command line length. ".
          "This may take up to 1 minute.")
    }

Also note that it only figures this out first time, after which it’s cached on disk.

▲

dataflow 8 hours ago | parent [-]

This is on MSYS2, yes, and that excuses absolutely nothing, because this shouldn't be happening in the first place for speed to be even relevant. At the risk of repeating myself thrice: the messages are confusing, the Ctrl+C handling is just utterly broken, the citation message adds to the confusion while being frankly obnoxious, and all of the delays and outputs are unnecessary in the first place as proven by literally every other program that doesn't make me wait a minute before I can use it the first time, including xargs. If Microsoft's own Windows tools did this, everybody would bash them (no pun intended) till the end of time. But since it's GNU Parallel and not Microsoft Parallel, it's Windows's fault for being slow and also my fault for having the audacity to expect better, apparently.

	▲	MrDOS 4 hours ago \| parent [-]
		> the messages are confusing > while being frankly obnoxious Try reading some time. It's pretty great. > the Ctrl+C handling is just utterly broken That's your terminal, not parallel. > and all of the delays Your terminal is adding the delay, not parallel. parallel is just warning you about your broken terminal. You're shooting the messenger here.

▲ 9 hours ago | parent | prev [-]

[deleted]