5 ms·
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.
by pornel 5y ago
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.
- Taywee 5y agoThe 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.
- guerrilla 5y agoIn that case, pick the system which is statistically dominant and clone that. That'd be GNU first and FreeBSD second. The standard can be some subset of their behavior.
- capableweb 5y agoOr, add a new standard describing the wanted behavior from `which` which everyone is already using, but put it under a new binary name. If it's supposed to show the path for the thing passed in, maybe `where` would make sense.
- gnubison 5y agoThat’s not usually how standards are supposed to work — a POSIX operating system should not reimplement Linux, it should only have to reimplement what’s portable to existing systems.
- StillBored 5y agoExcept POSIX has historically always been the intersection of the major Unix vendors. Which is why its always been the lowest common denominator, and is largely crap as a result. Of course to a certain extend all non defacto-standards suffer from this because invariably one group or the other doesn't want to rework their system to fit the standard so they NAK it.
- gnubison 5y agoPOSIX does simplify things, diverging from historical practice, when it’s reasonably the only way to standardize stuff that arguably should be standardized. And the vast majority of scripts are easily converted to POSIX-compliant shell script anyways — it’s certainly not “largely crap”.
- deleted 5y ago[deleted]
- jchw 5y agoThe behavior of which on different machines has a meaningful enough common subset that I would argue most people have absolutely no idea that there are this many different implementations. It’s possible this would lead to an undesirable standard that specifies less behavior than it should, but on the other hand, I believe that is easier to improve incrementally rather than all in one bandaid rip.
- mjevans 5y agoMinimally breaking solution 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.
- rezonant 5y agoThis is shockingly obvious and it's sort of crazy that it doesn't seem to be discussed [edit: in the overall discussion not just this thread]
- kjeetgill 5y agoI feel like I'm going to be bit when I try commands interactively and then that act differently in a script. I think the current solution is the pragmatic one, don't standardize things you can't pull off standardizing! #!
- hibbelig 5y agoThe ls command does this: if output is to a tty then it prints in columns. Many commands add color when the output is a tty. I don’t think it would be a big issue.
- rolandog 5y agoNot the person you replied to, but I hadn't thought about that particular difference and I take it for granted, so thanks for bringing it up!
- zaarn 5y agoThe simple solution could be that POSIX defines that if the output has a leading slash, it references a path where the command inputted can be found. Any other output is informational in nature only and has no standard texts.
- cryptonector 5y agoThat is NOT a problem. Because which is an external program, it can't know about things like shell aliases and functions, and that's OK because users know it or expect it. Indeed, if you're writing a script then you already know what aliases and functions are in it, and you're only going to be interested in knowing what's outside the script -- which(1) does that just fine. Stop looking for problems to solve where there are no problems. It's a waste of others' time, not just your own. Be respectful of others' time.
- seanhunter 5y agoThis was the case for literally all of the unix toolset before Posix came along, and how they solved this exact problem in every other case was to define a common subset (which usually involves almost all the functionality you really actually use most of the time) and make that the standard and everyone implements anything that's missing from the standard into their version and keeps all their existing extensions. That's why on linux you can do 'ps -leAf' or 'ps auxww' and have them do almost exactly the same thing for example.
- marcosdumay 5y ago> "but it's non-standard!" can be fixed by making it a standard. But which which do you make standard? When one says it's non-standard, it normally means that you don't know if the way you are using it will work on other places.
- josefx 5y agoUnix predates POSIX -> All Unix flavors were non standard + your reasoning -> POSIX cannot exist.
- marcosdumay 5y agoMaking it standard is a lot of hard work while you make a lot of people argue and act in a way that makes sure that some part of the thing will work everywhere. Standards exist on the real world, you can't just define them into existence without doing the work.
- pxc 5y ago> I'm a descriptivist when it comes to standards You can't quite be. Standards are norms, so there's no escaping normativity there. And simply describing existing conventions can't solve the problems that standards are introduced to solve, which is when you are faced with multiple, sometimes incompatible ways of doing things. There's room for a kind of descriptivist reconciliation with updates to standards, though. You can say ‘Future versions of the standard should, as far as possible, directly incorporate contemporaneous usage. Where contemporaneous usage is divergent, they should reflect the virtues of contemporaneous usage in a new standard capable of replacing divergent uses.’
- sneak 5y agoAlso, 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.
- anthk 5y agoFreeBSD with ZFS and being the backend of network CDN's wants a word or two with you.
- sofixa 5y agoLots of specialised hardware ( networking or storage for instance) uses various flavours of *BSD under the hood, which is reflected in the main enterprise contributors to FreeBSD.
- gnubison 5y agoMaybe one day you’ll try out OpenBSD and find that you actually like it… and then you’ll be hit by the force of hundreds of thousands of software developers who subscribe to the philosophy you describe above. Standards are important — they’re the balance between a monopoly and a fragmented ecosystem, and give developers a chance to create new platforms that can innovate while supporting existing code.
- arp242 5y agoThat's just not true. There are various BSD systems, AIX, HP-UX, Solaris, etc. still exists, Alpine uses busybox. Hell, I still see people being stuck with csh scripting sometimes with no alternative (sucks to be them!) There is some common software that wants to run on all these platforms. Do you or I need to care about that for our Docker build script or whatnot? No, probably not. But that doesn't mean others don't. There's still very much a valid use-case for POSIX, even though it doesn't apply to everything.
- matheusmoreira 5y agoI don't understand why people even care about POSIX in 2021. It's not like Linux distributions are POSIX certified. So many things can't be good because it's not in POSIX or because POSIX requires something else. People actually force themselves to write scripts in some mythical POSIX shell that nobody uses.
- arp242 5y agoThere are some cases where it makes sense. For example let's say I was developing something like a build script for ncurses: that runs on many different systems, and sticking to POSIX for compatibility makes sense there. There still quite a bit of stuff like that. But a lot of the time I see people write some shell script that's Linux or BSD specific in the first place as "compatible" shell scripts. I don't see how that makes much sense. The only advantage I can see is that dash is a bit faster than bash or zsh, but it's not that much of a difference in real scripts.
- scbrg 5y ago> The only advantage I can see is that dash is a bit faster than bash or zsh, but it's not that much of a difference in real scripts. It also consumes quite a bit less memory, which can be relevant for shell wrappers or other long running scripts. That's the primary reason I started writing my scripts for dash rather than bash. The other advantages (portability, lack of cognitive overload caused by bash's infinitely long list of features and quirks) were an unforeseen bonus.
- crehn 5y agoIt's minimal effort to maximize compatibility and consistency, regardless of where the script may be run. Shell scripts can run in a myriad of hosts, from VMs to stripped-down containers. When writing robust production code (not to say that shell scripts are ideal for that purpose), you'll want to minimize moving parts and risk surface, so that you can go home more confident that things will just work regardless of what you throw at it.
- rascul 5y agoI don't see that there's a POSIX way to provide the same functionality of 'which' without searching $PATH yourself.
- hibbelig 5y agoThe article mentions “command -v”.