5 ms·

Remember though, just because the shell on your rolling-release dev machine fixed this issue years ago, does not mean the shells on all your users/clients/legac

Remember though, just because the shell on your rolling-release dev machine fixed this issue years ago, does not mean the shells on all your users/clients/legacy servers/hobby backports have fixed the issue too.

MontyCarloHall 4y ago
>However, the value was mostly gone by the mid-to-late 1990s, and the few remaining issues were cleaned up before 2010 — shockingly late, but still over a decade ago. Anyone running a shell that still requires the x-hack is deliberately maintaining a legacy system, at which point the onus is on them to get modern tooling working on their machine.
- pfortuny 4y ago
  Being forgiving towards the user is one of the important principles of programming. Because the user may not be able to “upgrade” his system. Windows 95 is still very much alive. Embedded-like systems are a thing.
  - Macha 4y ago
    Yet asking for windows 95 support on most open source bug trackers will get a reaction between being laughed off the tracker or "do it yourself, but we'll reject the PR if it makes too much of a mess". I don't see why legacy commercial Unix deserves any higher level of support these days.
    - pfortuny 4y ago
      Did not say so. Only that if one does do it, one is being understanding. Did not say it has to be done.
    - JohnFen 4y ago
      Just because some projects (OSS or not) decide on a certain policy doesn't mean that the policy is necessarily good, or that any other projects should follow suit. Whether or not this is a reasonable stance depends on the project and the target demographic.
  - coldpie 4y ago
    > Being forgiving towards the user is one of the important principles of programming. Because the user may not be able to “upgrade” his system. Yes. If there is one thing I wish I could drill into every programmer's head, it's that not breaking stuff for your users is the #1 most important thing. There is one of you, and there may be many thousands of users. You putting in the extra effort means saving thousands of times of effort from your downstream users. Sometimes breakage unavoidable, but those instances should be rare, extremely well communicated, and felt as a failure to be learned from and avoided in the future. I don't care how ugly it makes things for you, your users are paramount.
    - lanstin 4y ago
      This isn’t even a moral principal - design systems and projects according to this discipline and you yourself will be repaid in extra robustness and less work in the long run, as well as happier users. Plus it is fun coming up with work around for obscure corner cases.
    - JohnFen 4y ago
      > not breaking stuff for your users is the #1 most important thing I would say that's #2. #1 is to never cause data loss.
      - archgoon 4y ago
        [dead]
  - H4ZB7 4y ago
    this is a perfect example of how UN*Xoids like to enamor themselves that they are the last bastion of responsible devs maintaining the 30 year old system that was never good to begin with from breaking
  - naniwaduni 4y ago
    Outside of very specific situations that you'll know if you're in them, when are you expecting someone to simultaneously (a) insist on running ancient software that they can't update to decades-old standards and (b) run your new software?
  - freedomben 4y ago
    > Windows 95 is still very much alive. Can you share any examples/use-cases? I'm not doubting you, I'm just very, very curious. In 2011 a customer I worked with was using Windows 95 still in a test bed for their legacy equipment. The test software they had was written for it, and it still worked, so no need to go through the massive pain of updating. But even that was 12 years ago and we expected it to fall apart any day...
    - bcrl 4y ago
      A friend of mine still helps out a number of local businesses running their old MS-DOS Point Of Sales terminal software, as well as old high end printing hardware at a print shop. It works, and replacements aren't worth the CapEx as they're doing just fine. Migration has real costs, like losing the customer database for a mechanic's garage or buying a new 6 digit printer for the print shop.
- Asooka 4y ago
  I get what you're saying, but the fix to support that old shell is literally two characters. If you don't want to support it, it would be good courtesy at least to print an error and abort, lest the buggy behaviour ends up damaging the user's system.
  - SAI_Peregrinus 4y ago
    Agreed. Abort with a clear message on unsupported systems. In this case, non-POSIX shells. The alternative is to bundle all the dependencies, including the shell interpreter into some maximally portable setup.
- JohnFen 4y ago
  I think telling your customers who rely on older systems to go pound sand is a good way to lose customers. Not to mention a bit callous.
  - nailer 4y ago
    Sure but if those customers are 1% of your revenue and 30% of your tickets then they're customers you want to lose and it's not particularly callous to want to feed your family.
    - JohnFen 4y ago
      Sure, but that's not the case for every business. I'm not saying that everyone needs to keep legacy support in mind. I'm saying that just taking the attitude of "it's old, too bad" is not good blanket practice. It all depends on what you're doing. > it's not particularly callous to want to feed your family The callous part is taking a disdainful attitude toward those customers.
      - nailer 4y ago
        > The callous part is taking a disdainful attitude toward those customers. I guess I thought it was obvious that most of the the time someone doesn't want to support legacy it's for this reason, not because of disdain for them.
        jrumbut 4y ago
        That's what disdain is though (in a very literal sense), not feeling that someone is worth your time or consideration. Your disdain of legacy clients might be profitable or understandable or even morally just, but it's still disdain.
        nailer 4y ago
        > disdain somebody/something to think that somebody/something does not deserve your respect or interest OED. You can respect someone but know their business isn’t worth your effort.
- aliher1911 4y ago
  Most recent MacOS is still shipped with bash 3.2.57 FWIF. Since default was changed to zsh they would likely never bump bash. So you never know.
  - matthew-wegner 4y ago
    That's still a 2014 release--definitely modern relative to the releases talked about in the article.
  - inferiorhuman 4y ago
    That was a licensing issue. It's pretty much guaranteed Apple will never ship a newer version of bash.
- niccl 4y ago
  up until last year I was supporting a system for a client that would only run on Solaris 2.5.2 from 1996 or so. (finding working versions of the hardware was becoming _really_ hard). The system was retired last year, replaced by something that costs several million dollars, but until then I had no choice. There are other things like that out there. I think I recall seeing something on HN fairly recently abut a controller for some CNC machine that was running an early version of MSDOS. Again, replacing with something more modern was very expensive. These things exist and the users aren't necessarily being wilfully malign in not upgrading
- deleted 4y ago
  [deleted]
skrebbel 4y ago
You really want to cater to people who chose to install Dash, and then not update it for 8 years?
- johnbellone 4y ago
  Revenue has no bounds.
  - psd1 4y ago
    Well yes it does, when it is exceeded by the cost or hassle of earning it. I won't support Windows 95 for a pittance
- naniwaduni 4y ago
  I'm not sure any dash has ever been broken in a way that would be worked around by the x-hack. This is an issue for, basically, pre-standard shells.
  - skrebbel 4y ago
    Don’t shoot the messenger, please. I never even heard of Dash before reading this article. I’m only quoting the article, which states that the last shell that needs the x-hack in some weird edge case is Dash and it got fixed in 2015.
    - naniwaduni 4y ago
      Fair enough! I guess we just have to conclude that it's for very good reason that POSIX basically throws its hands up and only tries to comprehensively specify behavior without conjunctions.
    - LordDragonfang 4y ago
      Dash got fixed in 2009. It's zsh (which isn't even POSIX compliant by default) that didn't get fixed until 2015. And almost all zsh users are either powerusers who should know how to update their damn shell, or post-2019-mac users who should let Apple do it for them.
quotemstr 4y ago
Yes it does. Sorry, I'm not supporting some ancient buggy AIX thing. People tying their shell scripts into knots using hacks like this are just doing performative compatibility nonsense. It hasn't mattered in the real world in a decade.
- naniwaduni 4y ago
  Also, this is hardly going to be the deal-breaker for running your software on such systems unless you're expressly writing for them. Pre-standard systems are exotic in ways that are going to break whatever you're trying to do in way more exciting ways!
- JohnFen 4y ago
  > It hasn't mattered in the real world in a decade. This is not true at all. There are plenty of such systems, run by major companies, in daily use. It isn't the most common case, but it certainly matters in important parts of the real world.
  - freedomben 4y ago
    Are we talking about a real example here? I'm very sympathetic to backwards compatibility, to the point I still write sh compatible scripts unless I have a real need for `[[ ~= ]]`, but of the thousands of scripts I've written in the last 10 years, none of them would have any use outside of a modern distro. Adding the x-hack to every comparison seems utterly insane to me, exactly as GP said. But like I said, I'm sympathetic, so I'd love to hear a case for why I should do it anyway
    - JohnFen 4y ago
      In my last position, I had to write new (and maintain old) shell scripts for these systems all the time, for Fortune 500 companies. Upgrading those systems was not in the realm of possibility for various reasons. Because our product has to run on a wide variety of hardware, it was essential to maintain compatibility both for the crufty old shell implementations and the shiny new -- so best practice there was to develop the habit of writing shell code that could run across the eons, including the x-hack. Multimillion dollar contracts depended on it. If your situation isn't like that, then I understand why this is a nonissue. But there are plenty of situations where such backward compatibility is essential. Not the most common thing, perhaps, but not as rare as some think. I do think there is a tendency amongst some programmers to think that everyone is running stuff that is at least moderately modern. In the real world, this is simply not true.
kazinator 4y ago
That is false. The only systems which have /bin/sh shells that have that sort of bug are proprietary Unixes, which also ship improved shells that better conform with POSIX, installed in a different location. A much smarter thing is for the script to detect, at the top, that it's running on a crappy /bin/sh, find the better shell, and re-execute itself with that shell (setting some environment variable to prevent recursion). Then the rest of the script doesn't have to use unusually stupefying coding techniques. Just the regular stupefying techniques.
SAI_Peregrinus 4y ago
IMO either write pure POSIX shell (no BASHisms or assuming external programs not guaranteed by POSIX exist, no assuming FHS paths are in use, etc) or require a specific shell and set of dependencies. Check for that at the start, exit with error if things aren't found. Scripts and programs will always get run in unsupported (broken) environments. If your program can't exit with a clear error in such a situation, it's not very portable. Personally I tend to use the multi-line nix-shell shebang: #! /usr/bin/env nix-shell #! nix-shell -i SHELL -p DEPENDENCIES #! nix-shell -I nixpkgs=NIXPKGS_TARBALL_URL If you want `bash` as your shell, then `bash` goes in the SHELL location and as one of the DEPENDENCIES. If you want GNU coreutils that goes in DEPENDENCIES. Etc. The last line is optional, it pins the versions of all the dependencies you want. This also works for Python scripts.

MontyCarloHall 4y ago

>However, the value was mostly gone by the mid-to-late 1990s, and the few remaining issues were cleaned up before 2010 — shockingly late, but still over a decade ago. Anyone running a shell that still requires the x-hack is deliberately maintaining a legacy system, at which point the onus is on them to get modern tooling working on their machine.

pfortuny 4y ago
Being forgiving towards the user is one of the important principles of programming. Because the user may not be able to “upgrade” his system. Windows 95 is still very much alive. Embedded-like systems are a thing.
- Macha 4y ago
  Yet asking for windows 95 support on most open source bug trackers will get a reaction between being laughed off the tracker or "do it yourself, but we'll reject the PR if it makes too much of a mess". I don't see why legacy commercial Unix deserves any higher level of support these days.
  - pfortuny 4y ago
    Did not say so. Only that if one does do it, one is being understanding. Did not say it has to be done.
  - JohnFen 4y ago
    Just because some projects (OSS or not) decide on a certain policy doesn't mean that the policy is necessarily good, or that any other projects should follow suit. Whether or not this is a reasonable stance depends on the project and the target demographic.
- coldpie 4y ago
  > Being forgiving towards the user is one of the important principles of programming. Because the user may not be able to “upgrade” his system. Yes. If there is one thing I wish I could drill into every programmer's head, it's that not breaking stuff for your users is the #1 most important thing. There is one of you, and there may be many thousands of users. You putting in the extra effort means saving thousands of times of effort from your downstream users. Sometimes breakage unavoidable, but those instances should be rare, extremely well communicated, and felt as a failure to be learned from and avoided in the future. I don't care how ugly it makes things for you, your users are paramount.
  - lanstin 4y ago
    This isn’t even a moral principal - design systems and projects according to this discipline and you yourself will be repaid in extra robustness and less work in the long run, as well as happier users. Plus it is fun coming up with work around for obscure corner cases.
  - JohnFen 4y ago
    > not breaking stuff for your users is the #1 most important thing I would say that's #2. #1 is to never cause data loss.
    - archgoon 4y ago
      [dead]
- H4ZB7 4y ago
  this is a perfect example of how UN*Xoids like to enamor themselves that they are the last bastion of responsible devs maintaining the 30 year old system that was never good to begin with from breaking
- naniwaduni 4y ago
  Outside of very specific situations that you'll know if you're in them, when are you expecting someone to simultaneously (a) insist on running ancient software that they can't update to decades-old standards and (b) run your new software?
- freedomben 4y ago
  > Windows 95 is still very much alive. Can you share any examples/use-cases? I'm not doubting you, I'm just very, very curious. In 2011 a customer I worked with was using Windows 95 still in a test bed for their legacy equipment. The test software they had was written for it, and it still worked, so no need to go through the massive pain of updating. But even that was 12 years ago and we expected it to fall apart any day...
  - bcrl 4y ago
    A friend of mine still helps out a number of local businesses running their old MS-DOS Point Of Sales terminal software, as well as old high end printing hardware at a print shop. It works, and replacements aren't worth the CapEx as they're doing just fine. Migration has real costs, like losing the customer database for a mechanic's garage or buying a new 6 digit printer for the print shop.
Asooka 4y ago
I get what you're saying, but the fix to support that old shell is literally two characters. If you don't want to support it, it would be good courtesy at least to print an error and abort, lest the buggy behaviour ends up damaging the user's system.
- SAI_Peregrinus 4y ago
  Agreed. Abort with a clear message on unsupported systems. In this case, non-POSIX shells. The alternative is to bundle all the dependencies, including the shell interpreter into some maximally portable setup.
JohnFen 4y ago
I think telling your customers who rely on older systems to go pound sand is a good way to lose customers. Not to mention a bit callous.
- nailer 4y ago
  Sure but if those customers are 1% of your revenue and 30% of your tickets then they're customers you want to lose and it's not particularly callous to want to feed your family.
  - JohnFen 4y ago
    Sure, but that's not the case for every business. I'm not saying that everyone needs to keep legacy support in mind. I'm saying that just taking the attitude of "it's old, too bad" is not good blanket practice. It all depends on what you're doing. > it's not particularly callous to want to feed your family The callous part is taking a disdainful attitude toward those customers.
    - nailer 4y ago
      > The callous part is taking a disdainful attitude toward those customers. I guess I thought it was obvious that most of the the time someone doesn't want to support legacy it's for this reason, not because of disdain for them.
      - jrumbut 4y ago
        That's what disdain is though (in a very literal sense), not feeling that someone is worth your time or consideration. Your disdain of legacy clients might be profitable or understandable or even morally just, but it's still disdain.
        nailer 4y ago
        > disdain somebody/something to think that somebody/something does not deserve your respect or interest OED. You can respect someone but know their business isn’t worth your effort.
aliher1911 4y ago
Most recent MacOS is still shipped with bash 3.2.57 FWIF. Since default was changed to zsh they would likely never bump bash. So you never know.
- matthew-wegner 4y ago
  That's still a 2014 release--definitely modern relative to the releases talked about in the article.
- inferiorhuman 4y ago
  That was a licensing issue. It's pretty much guaranteed Apple will never ship a newer version of bash.
niccl 4y ago
up until last year I was supporting a system for a client that would only run on Solaris 2.5.2 from 1996 or so. (finding working versions of the hardware was becoming _really_ hard). The system was retired last year, replaced by something that costs several million dollars, but until then I had no choice. There are other things like that out there. I think I recall seeing something on HN fairly recently abut a controller for some CNC machine that was running an early version of MSDOS. Again, replacing with something more modern was very expensive. These things exist and the users aren't necessarily being wilfully malign in not upgrading
deleted 4y ago
[deleted]

skrebbel 4y ago

You really want to cater to people who chose to install Dash, and then not update it for 8 years?

johnbellone 4y ago
Revenue has no bounds.
- psd1 4y ago
  Well yes it does, when it is exceeded by the cost or hassle of earning it. I won't support Windows 95 for a pittance
naniwaduni 4y ago
I'm not sure any dash has ever been broken in a way that would be worked around by the x-hack. This is an issue for, basically, pre-standard shells.
- skrebbel 4y ago
  Don’t shoot the messenger, please. I never even heard of Dash before reading this article. I’m only quoting the article, which states that the last shell that needs the x-hack in some weird edge case is Dash and it got fixed in 2015.
  - naniwaduni 4y ago
    Fair enough! I guess we just have to conclude that it's for very good reason that POSIX basically throws its hands up and only tries to comprehensively specify behavior without conjunctions.
  - LordDragonfang 4y ago
    Dash got fixed in 2009. It's zsh (which isn't even POSIX compliant by default) that didn't get fixed until 2015. And almost all zsh users are either powerusers who should know how to update their damn shell, or post-2019-mac users who should let Apple do it for them.

quotemstr 4y ago

Yes it does. Sorry, I'm not supporting some ancient buggy AIX thing. People tying their shell scripts into knots using hacks like this are just doing performative compatibility nonsense. It hasn't mattered in the real world in a decade.

naniwaduni 4y ago
Also, this is hardly going to be the deal-breaker for running your software on such systems unless you're expressly writing for them. Pre-standard systems are exotic in ways that are going to break whatever you're trying to do in way more exciting ways!
JohnFen 4y ago
> It hasn't mattered in the real world in a decade. This is not true at all. There are plenty of such systems, run by major companies, in daily use. It isn't the most common case, but it certainly matters in important parts of the real world.
- freedomben 4y ago
  Are we talking about a real example here? I'm very sympathetic to backwards compatibility, to the point I still write sh compatible scripts unless I have a real need for `[[ ~= ]]`, but of the thousands of scripts I've written in the last 10 years, none of them would have any use outside of a modern distro. Adding the x-hack to every comparison seems utterly insane to me, exactly as GP said. But like I said, I'm sympathetic, so I'd love to hear a case for why I should do it anyway
  - JohnFen 4y ago
    In my last position, I had to write new (and maintain old) shell scripts for these systems all the time, for Fortune 500 companies. Upgrading those systems was not in the realm of possibility for various reasons. Because our product has to run on a wide variety of hardware, it was essential to maintain compatibility both for the crufty old shell implementations and the shiny new -- so best practice there was to develop the habit of writing shell code that could run across the eons, including the x-hack. Multimillion dollar contracts depended on it. If your situation isn't like that, then I understand why this is a nonissue. But there are plenty of situations where such backward compatibility is essential. Not the most common thing, perhaps, but not as rare as some think. I do think there is a tendency amongst some programmers to think that everyone is running stuff that is at least moderately modern. In the real world, this is simply not true.

kazinator 4y ago

That is false. The only systems which have /bin/sh shells that have that sort of bug are proprietary Unixes, which also ship improved shells that better conform with POSIX, installed in a different location. A much smarter thing is for the script to detect, at the top, that it's running on a crappy /bin/sh, find the better shell, and re-execute itself with that shell (setting some environment variable to prevent recursion). Then the rest of the script doesn't have to use unusually stupefying coding techniques. Just the regular stupefying techniques.

SAI_Peregrinus 4y ago

IMO either write pure POSIX shell (no BASHisms or assuming external programs not guaranteed by POSIX exist, no assuming FHS paths are in use, etc) or require a specific shell and set of dependencies. Check for that at the start, exit with error if things aren't found. Scripts and programs will always get run in unsupported (broken) environments. If your program can't exit with a clear error in such a situation, it's not very portable. Personally I tend to use the multi-line nix-shell shebang: #! /usr/bin/env nix-shell #! nix-shell -i SHELL -p DEPENDENCIES #! nix-shell -I nixpkgs=NIXPKGS_TARBALL_URL If you want `bash` as your shell, then `bash` goes in the SHELL location and as one of the DEPENDENCIES. If you want GNU coreutils that goes in DEPENDENCIES. Etc. The last line is optional, it pins the versions of all the dependencies you want. This also works for Python scripts.