Non-standard command line option given to pax about dygraphs

[mirabilos]

hlovdal dixit:

$ pax --version spax: star 1.6 (x86_64-unknown-linux-gnu) 2019/04/01

Erk. Try with pax from MirBSD/Debian or even OpenBSD. Yes I’m aware of the Schily things… I’ll have a look at that in time, but not now. bye, //mirabilos -- „Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund, mksh auf jedem System zu installieren.“ -- XTaran auf der OpenRheinRuhr, ganz begeistert (EN: “[…]uhr.gz is a reason to install mksh on every system.”)

[mirabilos]

hlovdal dixit:

+ pax -rw -l node_modules disttmp/ pax: Unsupported option -l.

(ok, I did briefly look today) https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html (the current (soon to be old) version of POSIX) documents -l so I guess Schily just never got around to implementing it while he could. I suggest either to look into obtaining pax from MirBSD/Debian, which is the currently most widely-used, even if it actually lacks support for the pax format, or asking a possible new upstream for star or your distribution to add support for missing flags. bye, //mirabilos -- “It is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch.” -- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2

[mirabilos]

Yah, unfortunately still not implemented in current star.

I guess you got your pax from your distro. Switching needs much consideration, as other implementations both have more and less features, so offering both may be the best option.

Would it help if I packaged MirBSD/Debian’s up for RPM on the OpenSuSE buildservice? Which distro are you using?

[hlovdal]

But why use pax in the first place?

Cp or rsync would in general be much more available tools for copying files as hardlinks already present on potential contributer's machine, however this being a javascript project the obvious best choice would be to use a portable npm package like for instance sync-directory.

I cannot see any reason the failing pax command is better than

npx sync-directory --hardlink node_modules disttmp/node_modules

---

I started looking for alternatives to d3 due to its horrible unusable locale functionality, and landed on dygraphs and intended to test it out. But the usage of weird tools like pax and mksh for apparently no good reason was a really big turnoff. Like why mksh? There is nothing mksh provides that bash cannot do, and writing the shell scripts to invoke /bin/bash would make them 100% unproblematic for absolutely every single potential contributor (even windows users, the "git bash" environment that comes along when installing git is actually really decent).

One thing is to require a new tool to be installed when it does something that existing tools does not do, say converting some custom markdown to man pages or things like that, but requiring custom extra tools for copying files and running ordinary shell scripts? Really?

If you want people to contribute to this project I strongly suggest lowering the bar to entry by removing those hurdles. As an outside observer considering the health of a new project I can see that it is not dead which is good but the bus factor is extremely close to 1, the newest non-top contributor commit was made one year ago and the second newest two years ago.

[mirabilos]

hlovdal dixit:

But why use pax in the first place?

It’s standardised.

[Cp](https://unix.stackexchange.com/questions/202430/how-to-copy-a-directory-recursively-using-hardlinks-for-each-file)

Nōn-standard.

[rsync](https://superuser.com/questions/1360525/can-i-hard-link-files-with-rsync-instead-of-copying-them)

Overkill and hard to use.

this being a javascript project the obvious best choice would be to use a portable npm package like for instance [sync-directory](https://www.npmjs.com/package/sync-directory).

Absolutely not, these tend to not be available during Debian package builds. No NPM dependency allowed.

But the usage of weird tools like pax and mksh for apparently no good reason was a really big turnoff.

You don’t need these when you just download a release.

Like why mksh? There is nothing mksh provides that bash cannot do, and

That’s patently untrue (you’re talking to the mksh developer here), and it allows me to write much cleaner scripts.

writing the shell scripts to invoke `/bin/bash` would make them 100%

That’s unportable. bye, //mirabilos -- FWIW, I'm quite impressed with mksh interactively. I thought it was much *much* more bare bones. But it turns out it beats the living hell out of ksh93 in that respect. I'd even consider it for my daily use if I hadn't wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh

[hlovdal]

• How many contributors do you gain that think "Wow, this project uses pax and mksh, I'm in!"?
• How many contributors do you lose that think "Wtf, this project uses pax and mksh, I'm out!"?

The latter is several orders of magnitude greater than the first.

[mirabilos]

It’s a Javascript package, especially a Vanilla JS one. The tooling should not matter much. And you can always build this in GHA, in a Debian container or chroot…

Anyway, this is getting more and more off-topic, EOT.