best or most used technique when writing bash scripts...

sigint-ninja · 01-04-2016, 08:29 PM

hi guys,

im busy reading a good unix/linux sys admin book

on a section in bash scripts the book explains how to create scripts

but it uses this approach:

To summarize this approach:
• Develop the script (or script component) as a pipeline, one step at a time,
entirely on the command line.

• Send output to standard output and check to be sure it looks right.

• At each step, use the shell’s command history to recall pipelines and the
shell’s editing features to tweak them.

• Until the output looks right, you haven’t actually done anything, so
there’s nothing to undo if the command is incorrect.

• Once the output is correct, execute the actual commands and verify that
they worked as you intended.

• Use fc to capture your work, then clean it up and save it.

now i find this very interesting and it could take some time to get used to writing scripts this way...i have written a few and normally just use vi and then write down commands...

is it really important to write scripts using this approach,im guessing if its something rather small it could be handy...other than that use vi right?

lastly...what is the best way to test a script without having it actually execute or affect the system...do you just redirect it to a file?

thanks

suicidaleggroll · 01-04-2016, 08:36 PM

Doesn't everybody do this? You don't need to redirect or use fc, just use two terminal windows. One in the regular shell, one in a text editor. Use the shell to test the commands, once you have them right, copy/paste into the text editor to build up the script. You don't need to write out the entire thing in the shell, just the key parts that need some development (greps, awks, etc.).

sigint-ninja · 01-04-2016, 08:52 PM

ok i see what you mean...but what if im using a command thats affecting files...and i want to see the results without actually altering/changing a file...is there a way to do this...or would you just backup the file?

suicidaleggroll · 01-04-2016, 08:54 PM

Depends on what it's doing. If it's a rename/move you could just stick an "echo" in front of the command to print out what it's going to do without actually doing it. If it's actually modifying the file you'd need to back it up first.

You'd have the same dilemma running from a terminal as well, the command does what the command does, whether or not it's in a script.

sigint-ninja · 01-04-2016, 09:01 PM

thanks suicidaleggroll

i will follow your directions...what could i be focusing on regarding scripting to make me more valuable in the work place? i have no experience and have nowhere to turn.

thanks again

suicidaleggroll · 01-04-2016, 09:07 PM

I think string manipulation (including grep), variables, arrays, if statements, and for/while loops are the most important to get down. With that you can knock out most any script. There will of course be faster ways to do a lot of things, such as sed or awk one-liners, but that can come later.

zhjim · 01-05-2016, 02:26 AM

Finding possible flaws or rare case fails might be something up your sleeve. Also debugging scripts comes handy. Bash has some helpers here. Check out those three links to get a grip:
http://tldp.org/LDP/Bash-Beginners-G...ect_02_03.html
http://bashdb.sourceforge.net/bashdb.html
http://wiki.bash-hackers.org/scripting/debuggingtips

Habitual · 01-05-2016, 09:21 AM

http://www.shellcheck.net/
and I had to 'look up' fc in man bash - Thanks!
That explains why when I ran it, it stuck me into vi with history.

I use

Code:

VARIABLE=$(do stuff here)
echo $VARIABLE
...

And suicidaleggroll is correct, (any command that destroys should be thoroughly reviewed).

Code:

echo rm -fr /path/to/my/doom

is way better than just rm'ing it.

Code:

TRASH_THAT=$(rm -fr /path/to/my/doom)
echo $TRASH_THAT

would be safe.

Warning: Don't use this ^^^ code!

I tend to work on variables on not files directly when I write scripts/code.
but I live by echo when I write them.

Happy New Year!

BW-userx · 01-05-2016, 10:48 AM

Quote:

Originally Posted by sigint-ninja

ok i see what you mean...but what if im using a command thats affecting files...and i want to see the results without actually altering/changing a file...is there a way to do this...or would you just backup the file?

just echo what the results would be to the term without actually applying them

Code:

 

	# here where the name change would take place just echo it 
	# instead 
	#	mv -v "$path"/"$pref"."$ext" "$path"/"$NewFileName"

	echo " mv -v "$path"/"$pref"."$ext" "$path"/"$NewFileName" "

you can echo condistionals too in order to see whats going on

Code:

echo " [[ "$var" == "7" ]] "

you can

Code:

#!/bin/bash

set -x

to watch everything that is going on within your script

JockVSJock · 01-05-2016, 12:04 PM

Quote:

Originally Posted by Habitual

Code:

echo rm -fr /path/to/my/doom

Code:

TRASH_THAT=$(rm -fr /path/to/my/doom)
echo $TRASH_THAT

I tend to work on variables on not files directly when I write scripts/code.
but I live by echo when I write them.

Happy New Year!

I tried this from a script/term and didn't get any output or nothing. I don't understand how this would be safer then say straight from the terminal.

Code:

rm -rf /tmp/delete/*

On the other hand echoing the command as BW- user confirmed what I wanted to do:

Code:

$ echo rm -rf /tmp/delete/*
rm -rf /tmp/delete/foo1 /tmp/delete/foo2 /tmp/delete/foo3 /tmp/delete/foo4 /tmp/delete/foo5 /tmp/delete/foo6

BW-userx · 01-05-2016, 12:11 PM

Quote:

Originally Posted by JockVSJock

I tried this from a script/term and didn't get any output or nothing. I don't understand how this would be safer then say straight from the terminal.

Code:

rm -rf /tmp/delete/*

On the other hand echoing the command as BW- user confirmed what I wanted to do:

Code:

$ echo rm -rf /tmp/delete/*
rm -rf /tmp/delete/foo1 /tmp/delete/foo2 /tmp/delete/foo3 /tmp/delete/foo4 /tmp/delete/foo5 /tmp/delete/foo6

that actually removed my dir

Code:

[userx@Voided ~>$ Hot=$( rm -r $HOME/testing )
[userx@Voided ~>$ echo $Hot

[userx@Voided ~>$ Hot="$( rm -r $HOME/testing )"
rm: cannot remove ‘/home/userx/testing’: No such file or directory
[userx@Voided ~>$

Habitual · 01-05-2016, 01:00 PM

yeah, rm as a variable is a brain fart. Sorry.
My point was to emphasize the use of "echo"'ing stuff.

Code:

TRASH_THAT=$(echo rm -fr path/to/my/doom)
echo "$TRASH_THAT"

What gets me is his statement:

Quote:

Originally Posted by sigint-ninja

what is the best way to test a script without having it actually execute or affect the system...do you just redirect it to a file?

The OP wants to know how to "dry run" a script. Depends on the script.
To correctly test a script, one must write the script is my Final Answer.
It is not clear why the OP thinks redirecting is a testing technique...

BW-userx · 01-05-2016, 01:20 PM

Quote:

Originally Posted by Habitual

yeah, rm as a variable is a brain fart. Sorry.
My point was to emphasize the use of "echo"'ing stuff.

Code:

TRASH_THAT=$(echo rm -fr path/to/my/doom)
echo "$TRASH_THAT"

What gets me is his statement:

The OP wants to know how to "dry run" a script. Depends on the script.
To correctly test a script, one must write the script is my Final Answer.
It is not clear why the OP thinks redirecting is a testing technique...

more like a brain explotion lol --- I almost just ran that on / just to see .. that'd been a big oops - goood thing I changed my mind.

I do see the logic in it though - put it into a var first logic
did you even test that ever?

Quote:

To correctly test a script, one must write the script

yep

Habitual · 01-05-2016, 01:51 PM

Quote:

Originally Posted by BW-userx

more like a brain explotion lol

I earned it.
I would never put "rm -fr path/to/my/doom" into a variable. And edited my original post with a stern warning.
See my earlier comment about "echo"

Quote:

Originally Posted by BW-userx

more like a brain explotion lol --- I almost just ran that on / just to see .. that'd been a big oops - goood thing I changed my mind.

I do see the logic in it though - put it into a var first logic
did you even test that ever?

Sure did.

Code:

mkdir -pv path/to/my/doom
mkdir: created directory path
mkdir: created directory path/to
mkdir: created directory path/to/my
mkdir: created directory path/to/my/doom

TRASH_THAT=$(rm -fr path/to/my/doom)
echo $TRASH_THAT 
$
echo "$TRASH_THAT"
$

BW-userx · 01-05-2016, 02:20 PM

Quote:

Originally Posted by Habitual

I earned it.
I would never put "rm -fr path/to/my/doom" into a variable. And edited my original post with a stern warning.
See my earlier comment about "echo"

Sure did.

Code:

mkdir -pv path/to/my/doom
mkdir: created directory path
mkdir: created directory path/to
mkdir: created directory path/to/my
mkdir: created directory path/to/my/doom

TRASH_THAT=$(rm -fr path/to/my/doom)
echo $TRASH_THAT 
$
echo "$TRASH_THAT"
$

And the "Close the barn door after the horse has bolted testing method"
award goes to Habitual LQ Guru