The POSIX specification for ls's output is sufficiently precise[1] that it is quite reasonable to rely upon it. As a result, many scripts from a diverse array of vendors do so. A cursory glance at my home Ubuntu server has 'ls' invoked in many of the base package installation scripts and more besides.
One could sometimes use find(1) of course, but it has different semantics and output to ls unless you jump through some very silly command-line hoops that will make you say "should've just used ls".
As for the stat(1) program, which might be an alternative for individual files, it is not standardised, is not portable, and is in fact totally incompatible between GNU coreutils and BSD userland (including Mac OS).
> libxo imposes a large burden on system utilities. In the case of ls, that burden is difficult to justify -- any language that can interact with json output can use readdir(3) and stat(2).
Which rather misses the point of being able to use JSON in shell scripts.
Sorry if you interpreted my comment as advocating for tossing out grep or ls - that certainly wasn't what I was getting at. As one of the OpenBSD people that happens to quite like Rust, I'm aware of some of the other devs who have been using it, and we've talked a bit about Rust in general on occasion. The things that people appreciate about Rust tend to align with the things they like about OpenBSD, because the two projects have similar values. That's all I meant.
For at least _some_ *BSDs (Net, Free. Don't know about Open, Dragon Fly), see fstat(1) and sockstat(1) for functionally similar tools that ship with the base system. lsof(1) isn't part of base, but is available via ports/pkgsrc if lsof(1) is required or desired.
Agreed, this is the very reason I created a small script [1] to install them on non-OpenBSD systems. They are excellent for as references when coding C and to check what is most likely a GNU extension when writing portable shell scripts.
It is pretty trivial on FreeBSD to 'pkg install coreutils.' Then use the GNU versions of these utilities by prefixing 'g'. I actually alias several utilities to the GNU variants on my FreeBSD systems because I prefer their semantics.
(The point of my argument is: this is not an insurmountable problem.)
And as someone who, even nowadays, still points to the commercial manual pages for SCO Unix, HP/UX, AIX, Solaris, and suchlike, oftentimes for things that the GNU and BSD manual pages simply do not cover, I can tell you that you are quite wrong.
As can be seen, the commercial manual pages are not worse, and are indeed in several aspects better than the GNU one. The same is pretty much true of the non-GNU free operating systems (FreeBSD, OpenBSD, and Illumos) as well.
Notice that ...
* ... only the HP-UX, AIX, Solaris, Illumos, and OpenBSD manual pages have examples (quite apposite considering the headline for this discussion)
* ... only the HP-UX, AIX, Solaris, and Illumos manual pages explain that output falls into three basic forms
* ... only the Solaris, Illumos, and FreeBSD manual pages actually explain in detail the configuration of the colour scheme (HP-UX, AIX, and OpenBSD not having a colour scheme mechanism, in fairness)
* ... only the HP-UX, AIX, Solaris, Illumos, OpenBSD, and FreeBSD manual pages explain what the characters output by the -F option actually signify
* ... only the HP-UX, AIX, Solaris, Illumos, and FreeBSD manual pages explain that the time format used in -l changes according to how long ago the timestamp was (an odd removal for OpenBSD, considering that OpenBSD ls does the same thing)
> All FreeBSD scripts I encountered use posix shell.
Defaults matter, and it's helpful when the default shell for command-line use matches the shell used for scripting, because people often do scripting on the command line.
Take "ps", for example. The BSD "ps" program is fundamentally different to the Linux "ps" program. It's also, quite importantly, different to what the Linux "ps" manual erroneously claims the BSD "ps" to be.
As a Slackware and OpenBSD user I've really never understood this complaint. The init scripts they ship with are neither difficult to understand nor hard to read, and new ones are very easy to write.
Maybe the LSB stuff was awful; I never used it, and for that matter I can't think of a reason I would want to. It's the old FreeDesktop.org issue: it's a probably-interesting solution to a problem I just don't have.
One could sometimes use find(1) of course, but it has different semantics and output to ls unless you jump through some very silly command-line hoops that will make you say "should've just used ls".
As for the stat(1) program, which might be an alternative for individual files, it is not standardised, is not portable, and is in fact totally incompatible between GNU coreutils and BSD userland (including Mac OS).
[1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ls...
reply