6 ms·

-"As for scripting, commit to getting good at Bash." That advice can cause substantial headache on Ubuntu/Debian, where the Almquist shell is /bin/sh. This doe

• deleted 5y ago
  [deleted]
• cure 5y ago
  > That advice can cause substantial headache on Ubuntu/Debian, where the Almquist shell is /bin/sh. This does not implement much of bash and will fail spectacularly on the simplest of scripts. This is also an issue on systems using Busybox. At least for Debian and Ubuntu, that's why we start bash scripts with #!/bin/bash, of course. Your point is valid for Busybox, though.
  • netr0ute 5y ago
    Why would anyone want to target bash specifically which doesn't exist in all systems instead of just sticking to what's implemented in /bin/sh?
    • cure 5y ago
      Because you're not going to have a great time with /bin/sh (i.e. dash or the like) if you want to do anything more than very, very basic scripts.
      • netr0ute 5y ago
        Relying on bash is a recipe for non-portability.
        • lamontcg 5y ago
          If you're not publishing your scripts and you're running your own infrastructure, you probably don't care about portability at all.
          • chasil 5y ago
            None of the BSDs use bash in their base. Apple recently switched from bash to zsh. OpenBSD uses a descendent of pdksh. Another major user of a pdksh descendent is Android (mksh), with a truly massive install base. Some of the bash problem, besides portability, is GPLv3. That was a major factor for Apple. I don't want my script portability linked to corporate patent issues. For this and other reasons, I don't use bash-specific features, ever.
            • lamontcg 5y ago
              Yeah I've written and maintained scripts for the past 10 years that have to run on stock Solaris, AIX and *BSD. When they started out they had to work on the Solaris 9 /bin/sh, which is particularly elderly. You should feel free to continue to write portable scripts. That is horrible advice for anyone who is just starting out though and they should stick with #!/bin/bash and not worry about it until they actually want to consider platforms other than Linux. Portability is the wrong thing for people who are learning to focus on. It is also bad advice for most system administrators at most businesses since they won't have those alternative *nixes either, and its a best practice to minimize how many different operating systems you have to care about.
              • chasil 5y ago
                As we've already covered, Ubuntu is your downfall. Almquist is in Ubuntu for two reasons: speed and standards compliance. These may not be important to you, but they are to a great many people, and the horrible advice in this case is to disregard these factors.
    • massysett 5y ago
      You don't really know exactly what you'll get with /bin/sh - you might get bash trying to behave like sh, you might get dash. At least with /bin/bash you're hopefully getting bash. Now you just have to wonder what version...
  • chasil 5y ago
    > that's why we start bash scripts with #!/bin/bash That will also fail spectacularly, as bash does not behave the same when called as /bin/bash as it does when it is /bin/sh. I have principally noticed that aliases are not expanded in scripts unless a shopt is issued, which violates POSIX. Forcing POSIXLY_CORRECT might also help.
    • ericbarrett 5y ago
      Not sure what you are saying, bash behaves as bash when invoked as /bin/bash, and Bourne-shell-ish when invoked as /bin/sh. Lots more detail in the man page. I've never seen use of aliases in a bash script...? They are generally for CLI convenience.
      • chasil 5y ago
        Alias expansion within scripts is mandated by POSIX. When bash is not in POSIX mode, it violates the standard. $ ll /bin/sh lrwxrwxrwx. 1 root root 4 Nov 24 08:40 /bin/sh -> bash $ cat s1 #!/bin/sh alias p=printf p hello\\n $ cat s2 #!/bin/bash alias p=printf p world\\n $ ./s1 hello $ ./s2 ./s2: line 3: p: command not found
        • ericbarrett 5y ago
          That's very nice, it's POSIX-compliant when invoked as #!/bin/sh and sane when invoked as #!/bin/bash — exactly what I'd want.
          • chasil 5y ago
            If you want a portable script, then you don't want that behavior.
            • ericbarrett 5y ago
              Then I wouldn't put #!/bin/bash at the top.
• zokier 5y ago
  > That advice can cause substantial headache on Ubuntu/Debian, where the Almquist shell is /bin/sh. This does not implement much of bash and will fail spectacularly on the simplest of scripts. That's not really a problem as long as you use #!/bin/bash shebang, and there is nothing wrong in doing that.
  • NexRebular 5y ago
    Unless bash lives in /usr/local/bin/bash
    • nathanasmith 5y ago
      #!/usr/bin/env bash
    • chungy 5y ago
      and then you use "#!/usr/bin/env bash"
• johnchristopher 5y ago
  I settled with using /bin/sh for portability. If there is something that can't be done with sh but can be done with bash then it means a python script is better anyway. I don't want to deal with bashism and ksh and deb/ub/rh different takes on bash. It's frustrating that most google search results and shell script search results on SO almost always mean bash and sh.
  • jenscow 5y ago
    Yes, well if a script I wrote has somehow ended up on a machine without bash, then I'd be more worried about other assumptions the script makes.
    • johnchristopher 5y ago
      That's missing the point. Some server I know don't have vim. Traefik docker image is running ash and not bash. Tomcat image hasn't vim. Etc. /bin/sh is there. No worry about assumptions. No bashism, no fish, no zsh.
      • jenscow 5y ago
        That's fine. My scripts tend to run on a single machine.. otherwise, probably the same/similar Linux distro. So for me, if there's not even bash then I've also surely not accounted for other peculiarities on the system.
• encryptluks2 5y ago
  > -"As a practical goal, you should be able to recreate your host with a single Bash script." I disagree with this. A single bash script configuring an entire hosts can be overly complex and very difficult to follow. As someone who has created complex bash scripts, this will become very time consuming and prevent you from making many changes without significant efforts. I'd suggest familiarizing yourself with tools like cloud-init and Ansible.
  • deleted 5y ago
    [deleted]
  • jenscow 5y ago
    My take on that, was the host creation should be simple enough to only require bash.
  • chasil 5y ago
    "Relax and Recover" (rear) is a useful tool, written specifically in the bash dialect, that will write a compressed clone of your system to a bootable USB flash drive, network share (NFS/SMB), and other targets. Booting with rear, a (somewhat "klunky") interface will allow you to restore your captured backup, apparently pristine. It is similar in effect to the HP-UX Ignite tool that I used on that platform. Oracle has published a number of articles and blogs on or relating to it, and it is well worth study. The invocation of tar that preserves the SELinux contexts is particularly worth capturing.
    • encryptluks2 5y ago
      Yes, but capturing something is far different than being able to reproduce a system across multiple machines.
• notyourday 5y ago
  > That advice can cause substantial headache on Ubuntu/Debian, where the Almquist shell is /bin/sh. #!/bin/bash There, I fixed your "what shell is /bin/sh" problem.
  • chasil 5y ago
    Unless you actually look at real Linux deployments, which are: #!/bin/mksh Android doesn't allow GPL code in userland, and the installed base is massive.
    • notyourday 5y ago
      > Android doesn't allow GPL code in userland, and the installed base is massive. You aren't administering Android devices. Stop obsessing about writing portable scripts. Write scripts for the targets that you are going to run them on.
      • chasil 5y ago
        I run Lineage, and use a number of scripts. Stop ignoring standards. They exist for important reasons. Invent your existentialism in some other realm.
        • oblio 5y ago
          > Stop ignoring standards. That ship sailed when they froze that standard in time circa around 2008. People will always choose convenience over correctness. Fighting against that is fighting against human nature and it's a battle lost before it's begun.
        • notyourday 5y ago
          > I run Lineage, and use a number of scripts. There are people who dig trenches with spoons. It is not efficient and no one sane would be accounting for them. > Stop ignoring standards. They exist for important reasons. No. > Invent your existentialism in some other realm. I do. My target is Linux servers. Look at the topic : Reclaiming the lost art of Linux server administration" not "Finding another inefficient way to administer a phone"