Live data from Hacker News

Debian's Which Hunt

lwn.net

221–230 of 257 posts

Re: Debian's Which Hunt

#221
post #187

Earlier quoted context omitted.

You should be using ShellCheck or an equivalent linter on your shell scripts in POSIX mode if you want them to be portable; in POSIX mode it warns when using "which" instead of "command -v", and I think it also warns when using "whence" or "where" outside of zsh. There's a host of other Bashisms/GNUisms and other noncompliant antipatterns it checks for too. It's also worth reading through the POSIX manpages for POSIX…

> It's also worth reading through the POSIX manpages for POSIX sh if you want to be a good shell scripter. Or you can give the middle finger to POSIX, write shell scripts for bash, or even zsh, and end up with faster, more correct, and more beautiful shell scripts that in practice are just as portable as the ones that mindlessly follow the limited and bizarre POSIX shell spec. I'll write POSIXly-correct shell scripts…

Actually, regarding shells, the POSIX people pretend that it is still 1988.

The POSIX shell is the Bourne shell (1979) plus half of the innovations brought by ksh88.

The other half of the improvements from ksh88 and all of the improvements from ksh93 are not included in the POSIX shell standard.

Also for POSIX compliant shells one must not forget that also the other programs invoked by the shell must not be used with non-POSIX options.

For example, in a bash script I used the ksh93 syntax:

  ${VARIABLE:64:32}
Then I wanted to make it POSIX compliant and I rewrote it in the longer:

  $(expr substr "${VARIABLE}" 65 32)
But then I discovered that POSIX expr lacks substr, so I had to rewrite the expression into the even longer:

  $(awk -v s="${VARIABLE}" 'BEGIN {print substr(s, 65, 32)}')
which is the only POSIX compliant way to extract substrings.

In most cases the rational way is to write scripts for bash or zsh, which include all the ksh93 features plus brace expansion (from csh, then enhanced by zsh).

Writing POSIX compliant scripts results in much longer scripts in which the chances of bugs are much higher.

Re: Debian's Which Hunt

#222

Earlier quoted context omitted.

The systemd thing was extremely transparent. It didn't reach a solution that satisfied everybody, but there wasn't any secrecy on it.

Yes. I have no gripe about the process. (Well, I don't think it was a technical decision, so it shouldn't have been dumped on the TC). It was pellucidly transparent. Exemplary, really. I just really don't like systemd, so I'm sorry that it became the Debian default init. My gripe is with the outcome, not the process. Most package-maintainers must have disagreed with me. It's OK, I'm used to people not agreeing with m…

What tangible thing does systemd do that hurts your usage of the OS?

If I would hack into your computer, install systemd and set up a few clever aliases for your sysvinit commands, would you ever notice that I have done that?

I see this hard anti-systemd sentiment from some vocal people, but I have yet to see any actual problems that systemd has caused.

I know that systemd is not a POSIX standard, but neither is sysvinit.

Re: Debian's Which Hunt

#223
post #222

Earlier quoted context omitted.

Yes. I have no gripe about the process. (Well, I don't think it was a technical decision, so it shouldn't have been dumped on the TC). It was pellucidly transparent. Exemplary, really. I just really don't like systemd, so I'm sorry that it became the Debian default init. My gripe is with the outcome, not the process. Most package-maintainers must have disagreed with me. It's OK, I'm used to people not agreeing with m…

What tangible thing does systemd do that hurts your usage of the OS? If I would hack into your computer, install systemd and set up a few clever aliases for your sysvinit commands, would you ever notice that I have done that? I see this hard anti-systemd sentiment from some vocal people, but I have yet to see any actual problems that systemd has caused. I know that systemd is not a POSIX standard, but neither is sysv…

> What tangible thing does systemd do that hurts your usage of the OS?

Well, binary logging, for a start. Usurping DNS.

Actually, let's not go down that path - it would be a long argument, and I've already lost it, years ago.

> would you ever notice that I have done that?

Umm, yes.

My case isn't that systemd is bad; it's that I objected to Debian making systemd the default init, and that it's not very easy to make a non-default init the active init. I have a preference, I don't think I have to justify it, but the Debian change made it hard for me to exercise that preference. That's all.

Re: Debian's Which Hunt

#224
post #164

Earlier quoted context omitted.

Wouldn't stop me. :D Come to think of it, I never checked what Manjaro even means.

As the meme goes, you can use Arch without telling anyone about it

Oh yeah, and I do that 99% of the time. Only if somebody asks or if I want to make a point on HN.

As time goes by (I am 41) I really find it less and less appealing to argue with people, on HN included. People can tell you "just do X, you won't regret it!" or "use Y, most of your problems will go away" but you are there happily doing A and using B and they serve you perfectly.

So if I am asked about what would I recommend as best practices, I always say: "if you have needs X, Y and Z, then using A and B is perfect".

Just saying "use Arch, it's best Linux eva duuuuude" is of course unproductive.

Re: Debian's Which Hunt

#225
post #222

Earlier quoted context omitted.

What tangible thing does systemd do that hurts your usage of the OS? If I would hack into your computer, install systemd and set up a few clever aliases for your sysvinit commands, would you ever notice that I have done that? I see this hard anti-systemd sentiment from some vocal people, but I have yet to see any actual problems that systemd has caused. I know that systemd is not a POSIX standard, but neither is sysv…

> What tangible thing does systemd do that hurts your usage of the OS? Well, binary logging, for a start. Usurping DNS. Actually, let's not go down that path - it would be a long argument, and I've already lost it, years ago. > would you ever notice that I have done that? Umm, yes. My case isn't that systemd is bad; it's that I objected to Debian making systemd the default init, and that it's not very easy to make a…

I always feel like journald was not fully complete before major distros swapped over to systemd. I like the problems it was trying to solve and I get the reasons journald went with a binary database file.

I’ve personally been burned multiple times at work by log monitors missing log messages due to logrotate. It isn’t often, but often enough I’m glad for the solution.

The thing that hurt was that they did all this work for better structured data and then the only remote logging solution (that was really usable) at the time was syslog. Remote logging has gotten better depending on what sort of central logging vendor you’re using.

Re: Debian's Which Hunt

#226
post #84

Earlier quoted context omitted.

Wait what macOS has an executable called `command`? Does any other OS?

It’s a shell built-in.

No, macOS has an executable called `command` so that it is available even on shells that don't implement the builtin

Re: Debian's Which Hunt

#227
post #84

Earlier quoted context omitted.

Wait what macOS has an executable called `command`? Does any other OS?

BSD and Linux do.

What Linux distros do? The comments in the `command` script on macOS indicate that FreeBSD included a separate executable for `command` in 2005. But there's no package in all of Nixpkgs providing a `command` executable and the command-not-found handler for Ubuntu doesn't suggest anything either.

The norm, afaict, is for `command` to be a shell built-in only, and not available as a separate program.

Re: Debian's Which Hunt

#228
post #152

> * The POSIX-blessed way of finding an executable program is command -v, which is consequently built into most shells. Given the standard alternative, Adams said, "surely no one competent would choose to have a package depend on `which` when a standard POSIX utility can do a better job".* This feels a little tone-deaf to me. I've been using the *nix command-line and writing (and reading) shell scripts for 20+ years,…

My story would echo this same sentiment. Incidentally, running `man command` on OS X actually does not reference a '-v' option at all, instead only stating the more verbose `command which`. Both appear to work, but it further highlights your (our) discoverability issue(s).

`command which` just executes `which`

Re: Debian's Which Hunt

#229
post #222

Earlier quoted context omitted.

Yes. I have no gripe about the process. (Well, I don't think it was a technical decision, so it shouldn't have been dumped on the TC). It was pellucidly transparent. Exemplary, really. I just really don't like systemd, so I'm sorry that it became the Debian default init. My gripe is with the outcome, not the process. Most package-maintainers must have disagreed with me. It's OK, I'm used to people not agreeing with m…

What tangible thing does systemd do that hurts your usage of the OS? If I would hack into your computer, install systemd and set up a few clever aliases for your sysvinit commands, would you ever notice that I have done that? I see this hard anti-systemd sentiment from some vocal people, but I have yet to see any actual problems that systemd has caused. I know that systemd is not a POSIX standard, but neither is sysv…

Systemd broke my computers plenty of times; the closed logging system spread the logs into the things systemd managed and what the application manages; there were the DNS problems that Debian solved quickly; and the moronic timeouts, why fail a service in a second when you can keep retrying and increasing the timeout for 15 minutes, dragging the boot sequence and making sure nobody can fix the problem for all that time?

There were many more, but I don't write it down. Systemd is a horrible piece of software that solves a very important problem.

Re: Debian's Which Hunt

#230
post #157
post #84

Earlier quoted context omitted.

Wait what macOS has an executable called `command`? Does any other OS?

The article points out that "command -v" is the only thing in this mess that's actually standardized by POSIX as "print out the path to the thing specified".

The standard[1] is for a shell built-in, not a separate executable:

> Since command is a regular built-in utility it is always found prior to the PATH search.

That's why it's weird that macOS has an executable which wraps it from `sh`, which I've discovered since the GP is something it inherits from FreeBSD.

I'm not sure if FreeBSD still does this (some FreeBSD poster let me know), but apparently they used to generate wrappers for shell builtins pegged to #!/bin/sh and drop them in /usr/bin, presumably so that scripts running in non-POSIX shells that didn't implement them at all could still invoke them. It seems kinda neat. But it also leads to weird behavior where you can run `command` in tcsh and it will tell you something is a shell built-in even though it doesn't appear in the list of tcsh's shell builtins and you're running tcsh, which seems... wrong.

1: https://pubs.opengroup.org/onlinepubs/007904975/utilities/co...

Post reply on HN