i didnt care about how i wrote my bash scripts, coz i know theyd ultimately be used just by myself. but for the past few day, i’ve been working on this project, mk-blog which uses some bash scripts, there are chances that others might look at them. besides in work they’re asking me maintain a server. so why not learn the standards. but i couldn’t find anything good online (i’m gonna blame my search engine lol). so…

i’d appreciate redirections to (official or community) bash coding standards

  • demizerone@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    3 days ago

    If your bash script gets longer than 200 lines (including argument handling), use Python. I have to support bash APPLICATIONS at work and it’s a fucking nightmare to maintain.

    • Zucca@sopuli.xyz
      link
      fedilink
      arrow-up
      0
      ·
      edit-2
      3 days ago

      I would then assume those scripts weren’t written properly to begin with.

      But yes, shell scripts should be used (normally) to automate some simple tasks (file copying, backups…) or as an wrapper to exec some other program. I’ve written several shell scripts to automate things on my personal machines.

      However shell script can be complex program while at the same time being (somewhat) easy to maintain:

      • functions, use functions, alot
        • comment every function and describe what it expects in stdin or as an arguments
        • also comment what it outputs or sets

      This way at least I don’t break my scripts, when I need to modify a function or some way extend my scripts. Keeping the UNIX philosophy inside shell scripts: let one function do one thing well.

      And of course: YMMV. People have wastly different coding standards when it comes to personal little(?) projects.

        • Zucca@sopuli.xyz
          link
          fedilink
          arrow-up
          0
          ·
          2 days ago

          I had several tests at the beginning of the script. These tests define the “low-level” functions based the capability of the shell. To test new features I “simply” ran all the necessary commands on the test environments (bash, busybox, toybox+mksh).

          The script would error out if some necessary capability was missing from the host system. It also had a feature to switch shell if it found a better one (preferring busybox and its internal tools).

          Yeah… It was tedious process. It was one of those “I’ll write a simple script. So simple that it’ll work on almost every posixy shell.”… rest is history.

        • jbrains@sh.itjust.works
          link
          fedilink
          arrow-up
          0
          ·
          3 days ago

          I haven’t used it on a project for money, but I have some tests in shunit2 and that alone encourages me to extract code to functions.