131–140 of 257 posts
Earlier quoted context omitted.
Also, POSIX is basically irrelevant now. There are only two Unixen that anyone uses: RMS/Linux and whatever outdated garbage userspace Apple is shipping with macOS.
FreeBSD with ZFS and being the backend of network CDN's wants a word or two with you.
> 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". While I can understand having this attitude, a whole lot of package build scripts, not just in Debian, but in the upstreams, rely up…
> While I can understand having this attitude, a whole lot of package build scripts, not just in Debian, but in the upstreams, rely upon which existing and printing out the path of an executable without a deprecation warning. Probably not. The programs should (and likely actually do) parse only stdout. The warning is on stderr. I find the whole thing pointless, I disagree with Adams that only incompetent people would…
As of today all my (scripts') use of which is going to include '2>&1' or the contextually appropriate equivalent. Fuck Clint Adams.
Seems like this is a case of Debian governance working as designed. I'm surprised that 'which' isn't POSIX though.
Still a gigantic waste of everyone time. They could just have kept which has it has been for more than a decade and nothing would have happened. That's the decision that prevailed in the end but the fact that it had to go all the way to the Technical Committee before sanity prevailed says a lot about the utter madness of the Debian development process.
When I read stuff like this I can't help but wonder how anything ever even gets done on this project. The amazing thing is 'which' was working perfectly fine for everyone. Just leave it alone? The amount of time they wasted on debating this is staggering compared to just not changing it.
Many years ago, I posted that stable was too old. All the Debian users were quick to tell me to run testing, that it wasn't a bad experience in spite of the name. Well, after converting all my machines to Debian, a package that was critical to my work was broken and I was not at all impressed with the handling of the situation, so I moved on. I can definitely see something like the story in the article playing out.
When I read stuff like this I can't help but wonder how anything ever even gets done on this project. The amazing thing is 'which' was working perfectly fine for everyone. Just leave it alone? The amount of time they wasted on debating this is staggering compared to just not changing it.
> The amazing thing is 'which' was working perfectly fine for everyone. 'everyone' = existing users. New users are generally harmed by redundancy and mess.
As in all things, it is a balancing act.
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…
I'm a descriptivist when it comes to standards. When everyone uses `which`, POSIX should add it. "but it's non-standard!" can be fixed by making it a standard.
Also, POSIX is basically irrelevant now. There are only two Unixen that anyone uses: RMS/Linux and whatever outdated garbage userspace Apple is shipping with macOS.
I'm a descriptivist when it comes to standards. When everyone uses `which`, POSIX should add it. "but it's non-standard!" can be fixed by making it a standard.
The problem is that `which` behaves differently in many different existing use-cases (sometimes reporting aliases and sometimes not). If POSIX defines the behavior, then many existing uses become non-standard, and the existing implementations have to decide to change to become standard and possibly break backward compatibility or remain the same and stay non-standard.
1) Require the output of which in non-interactive environments to conform to the behavior a reasonable shell script author is likely to have assumed the specification was based on observations. In the case of historic 'which' that would be to print the absolute path to an executable without any other arguments, or a specific error message and exit status.
2) Allow __interactive__ shells to deviate from that behavior. E.G. with a warning, with alias information, etc.
Regardless of whether 'command -v' is a better alternative, 'which' is ensconced as standard practice in many shell scripts, and I would go so far as to say I think the majority of them that actually have to choose between the two use 'which'. Given that, having it print out a deprecation warning without considering what that means to all the people that use it is irresponsible. I help manage a few hundred servers. W…
Removing it from the standard distribution would be a huge annoyance to everyone who uses it. One more package you have to remember to install on every system to be productive.