Sponsored Content
Top Forums Shell Programming and Scripting Programming guidelines and style Post 303001684 by drl on Wednesday 9th of August 2017 11:38:33 AM
Old 08-09-2017
Hi.

This is a meta-answer for shell coding.

1) Write however you want, then run your code through a semantic and syntax checker:
Code:
shellcheck      analyse shell scripts (man)
Path    : /usr/bin/shellcheck
Version : ShellCheck - shell script analysis tool
Type    : ELF 64-bit LSB executable, x86-64, version 1 (SYSV ...)
Help    : probably available with -h
Repo    : Debian 8.8 (jessie) 
Home    : http://hackage.haskell.org/package/ShellCheck (pm)

As you progress, you can skip this as the first step, and go right to testing, coming back if your code fails.

then through a beautifier (which could easily apply to all languages):
Code:
beautysh        Tidy bash scripts, written in python3. (what)
Path    : ~/bin/beautysh
Version : - ( local: RepRev 1.4, ~/bin/beautysh, 2016-03-31 )
Length  : 174 lines
Type    : Python script, ASCII text executable
Shebang : #!/usr/bin/env python3
Home    : https://github.com/bemeurer/beautysh (doc)
Modules : (for python codes)
  re
  sys

2) Shell (as a programming language for more than trivial scripting) is dead. Perl rules in its place (though it is now being strongly challenged by Python). -- Basic Linux and Unix bibliography , especailly parts:

a) Books on Shell, Script, and Web Development

b) Good Programming Style

Best wishes ... cheers, drl
 

4 More Discussions You Might Find Interesting

1. Forum Support Area for Unregistered Users & Account Problems

Guidelines For Posting Here

This area is not for technical questions. It is reserved for unregistered users who have a question or registered users who have trouble with their account. Other posts will be deleted by the moderators. (0 Replies)
Discussion started by: Neo
0 Replies

2. What is on Your Mind?

Guidelines for Posting Here

This area is not for forum specific technical questions. Please post forum specific technical questions in the best forum, not in the lounge. However, if your idea or question is not covered clearly in a forum, please post it here. Discuss whatever is on your mind. Technical topics welcome... (0 Replies)
Discussion started by: Neo
0 Replies

3. Shell Programming and Scripting

Unix Shell Scripting Guidelines

Hi, I was wondering if any of you guys have developed shell scripting guidelines for writing unix shell scripts effectively. This includes naming standards, comments, indentation, error handing after unix comands, use of exported variables, sending notifications, functions, logging etc... ... (2 Replies)
Discussion started by: acheepi
2 Replies

4. Programming

Building Block style programming Book

Hello to all, Here is my situation. Some time in the mid-80's I stumbled across a small white programming book - can't remember the name but it was unique in that it started right out giving instructions on creating building blocks in code as a foundation for a complete system. The book was... (2 Replies)
Discussion started by: jozefn
2 Replies
SHELL-QUOTE(1p) 					User Contributed Perl Documentation					   SHELL-QUOTE(1p)

NAME
shell-quote - quote arguments for safe use, unmodified in a shell command SYNOPSIS
shell-quote [switch]... arg... DESCRIPTION
shell-quote lets you pass arbitrary strings through the shell so that they won't be changed by the shell. This lets you process commands or files with embedded white space or shell globbing characters safely. Here are a few examples. EXAMPLES
ssh preserving args When running a remote command with ssh, ssh doesn't preserve the separate arguments it receives. It just joins them with spaces and passes them to "$SHELL -c". This doesn't work as intended: ssh host touch 'hi there' # fails It creates 2 files, hi and there. Instead, do this: cmd=`shell-quote touch 'hi there'` ssh host "$cmd" This gives you just 1 file, hi there. process find output It's not ordinarily possible to process an arbitrary list of files output by find with a shell script. Anything you put in $IFS to split up the output could legitimately be in a file's name. Here's how you can do it using shell-quote: eval set -- `find -type f -print0 | xargs -0 shell-quote --` debug shell scripts shell-quote is better than echo for debugging shell scripts. debug() { [ -z "$debug" ] || shell-quote "debug:" "$@" } With echo you can't tell the difference between "debug 'foo bar'" and "debug foo bar", but with shell-quote you can. save a command for later shell-quote can be used to build up a shell command to run later. Say you want the user to be able to give you switches for a command you're going to run. If you don't want the switches to be re-evaluated by the shell (which is usually a good idea, else there are things the user can't pass through), you can do something like this: user_switches= while [ $# != 0 ] do case x$1 in x--pass-through) [ $# -gt 1 ] || die "need an argument for $1" user_switches="$user_switches "`shell-quote -- "$2"` shift;; # process other switches esac shift done # later eval "shell-quote some-command $user_switches my args" OPTIONS
--debug Turn debugging on. --help Show the usage message and die. --version Show the version number and exit. AVAILABILITY
The code is licensed under the GNU GPL. Check http://www.argon.org/~roderick/ or CPAN for updated versions. AUTHOR
Roderick Schertler <roderick@argon.org> perl v5.8.4 2005-05-03 SHELL-QUOTE(1p)
All times are GMT -4. The time now is 09:34 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy