5 ms·

No. Use standard POSIX flags to invoke standard POSIX functionality, so your scripts don't break when run on a different system.

• mauvehaus 14y ago
  I think, like most things, this would depend on who your audience is. For internal use only where you're running under a consistent environment at all times and aren't worried about portability, it probably makes sense to go with the more explicit long options. For something you're planning to deploy to customers, it probably makes sense to play it pretty strict with POSIX. Likewise, I usually script straight sh for portability if it's going to a customer unless there's a compelling reason to use bash. I'll mix in bash in stuff I write for myself where it makes my life simpler.
• jerf 14y ago
  It's always a cost/benefits analysis. I think for a lot of us, the cost/benefit goes something like this: "Will I ever have to read and modify this script again? Effectively-100% likely. Will this script ever run anywhere that I don't have the GNU toolchain? Effectively-0% likely." It's a no-brainer at that point. If you can't say that second part honestly, reconsider, but a lot of us can.
  • lamby 14y ago
    > Will this script ever run anywhere that I don't have the GNU toolchain? Effectively-0% likely. Not really. A lot of stuff broke when /bin/sh moved to a POSIX-compatibile shell rather than Bash.
    • njharman 14y ago
      No a lot of stuff broke because people depended on implicit rather than being explicit. #!/bin/bash
      • Wilya 14y ago
        wilya@home $ /bin/bash zsh: no such file or directory: /bin/bash wilya@home $ which bash /usr/local/bin/bash (Yes, I'm annoyed when I see #!/bin/bash, especially on scripts which are otherwise basic enough to be portable everywhere)
        • dfox 14y ago
          It is still better to write #!/bin/bash for bashism using scripts than #!/bin/sh. I recently had to run sed -i (well, another GNUism) 1s%/sh%/bash% on bunch of customer's scripts to make them work on debian. At least when script wants /bin/bash it is going to fail cleanly (and not in the middle after modifying random things) and with mostly meaningful error.
      • wollw 14y ago
        It's probably safer to use: #!/usr/bin/env bash Assuming env is installed (I believe I had to install a package on OpenBSD to use it) this will find the first instance of bash in the PATH.
        • atsaloli 14y ago
          How do you know env is in /usr/bin rather than in /bin or /usr/local/bin? I'm just curious...
          • wollw 14y ago
            You don't, but I've run into more problems with bash being in unexpected places than env.
            • atsaloli 14y ago
              Right on, thanks.
          • ralph 14y ago
            Good question. I've used systems, e.g. AIX, where env(1) was in /bin.
  • X-Istence 14y ago
    And now porting your script to non GNU such as BSD becomes a pain in the behind ... whereas before maybe only one or two commands would have had to change, now it will be most if not all.
    • jerf 14y ago
      When I mentioned "GNU", I think it sort of implied that I am aware of the existence of non-GNU toolchains. I really am not worried about that in my world. The dependencies on Linux go a great deal deeper than the GNU toolchain. YMMV.
  • papsosouid 14y ago
    >Will this script ever run anywhere that I don't have the GNU toolchain? Effectively-0% likely. That's not the case for most people though. I can't even remember the last time I saw even a tiny project assume the world is all "whatever gnu/linux distro I happen to use". Tons of people use linux distros that aren't ubuntu, tons of people use OSX, tons of people use a BSD.
• npsimons 14y ago
  Okay. Care to point us all to the official standard POSIX flags documentation? Even then, you are probably going to find that there are just as many systems that your script needs to run on that are POSIX incompatible as there are systems that don't recognize the long flags. My ultimate rule: write the code that is the most readable, because in 10, 15, 30 years, someone can easily update a script to working arguments from arguments with long words, whereas single letter arguments may have multiple different meanings on different systems. It's the same with naming conventions and code constructs: the how and the what should be obvious from the code.
  • kps 14y ago
    For documentation, this will do: http://pubs.opengroup.org/onlinepubs/009695399/utilities/contents.html http://pubs.opengroup.org/onlinepubs/009695399/utilities/con... What current systems have arguments that conflict with those?
    • npsimons 14y ago
      For documentation, this will do: http://pubs.opengroup.org/onlinepubs/009695399/utilities/con.. http://pubs.opengroup.org/onlinepubs/009695399/utilities/con.... Thank you for that. I was aware of the POSIX docs for C/system level programming, but I wasn't sure if command arguments were standardized. What current systems have arguments that conflict with those? Ah, but "current" is not always what we get. It's been a while, but I can vaguely remember conflicting single character arguments for basic commands (eg, ls, ps) on OSF/1, SunOS and Linux.