this post was submitted on 26 Jun 2024
88 points (96.8% liked)

Linux

48323 readers
632 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
88
submitted 5 months ago* (last edited 5 months ago) by t0mri@lemmy.ml to c/linux@lemmy.ml
 

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

you are viewing a single comment's thread
view the rest of the comments
[–] PseudoSpock@lemmy.dbzer0.com 31 points 5 months ago* (last edited 5 months ago) (5 children)

Don't know about everyone else, but here are some of mine:

  • Stick to posix compliance shell code, wherever possible
  • Please wrap your variables with { }. Just please.
  • Global variables being exported in all caps
  • Local variables in lower case
  • $() instead of ` `
  • Comment anything complicated, comment what section, comment usage
  • Include usage output if options are not recognized
  • Use case instead of if / elif, where possible
  • 80 characters or less per line, where possible
  • HERE docs in designated section, marked by comment blocks
  • Comment your functions immediately above it's definition
  • Add comment "#End of function Xyz" at line immediately below a function, with replacing Xyz with name of that function
  • 2 space indentation
  • Multi-line strings: First line open with quote and first line of string, followed by a backslash , subsequent lines properly indented and backslashed. Last line, properly indented and close quoted.
  • Break up multiple piping of commands with |\ and a new line where it makes sense to look nice, assisting readability
  • Echo what the script is doing once in a while if the user will be waiting for a while
  • Please don't do shar archives, or byte located binary extractions, make a script and a separate tarball - Helps a ton if we have to change it, like say... swapping out a bundled java runtime built for x86_64 with one for aarch64
  • If the script will run for a very long time, check for tmux or screen and also the TMOUT variable... Give a warning to the user their connection might time out before the script is done if they don't unset TMOUT, and try using tmux or screen to allow the script to continue in the background, even if you do get disconnected
  • Make use of logger
  • I try to organize a script this way: 1. Shebang, 2. Initial variable definitions, 3. Functions, 4. runtime execution code, which might be best outside of a function, and calling functions. 5. Clean-up (remove pid and lock files, tmp files, etc etc.)
[–] Zucca@sopuli.xyz 3 points 4 months ago
  • utilize awk if you need to process (=more complex than just grepping) large amounts of text.
    • make your awk code conform to at least busybox awk for compability

I once did a sh script that needed (because I wanted a challenge?) to be compatible with vanilla Android shell too. So I needed to test it with regular bash, busybox and mksh+toybox. That was 'fun'.

I've had some initial plans to spllit the code out from that project and develop a "shell" library that would ease building shell scripts that are compatible with different systems... But I bet someone else has already done that.

load more comments (4 replies)