Please use
[CODE][/CODE] tags around code and exact strings. It keeps indentation intact, and makes it much easier to read.
Quote:
Originally Posted by contra04
regex=("${regex[@]}" -e "s|interface Serial 0\/0|interface Serial 1\/0|g")
|
No need to escape slashes, as the separator character is
| . (At least GNU sed does not mind an extra backslash at all, so your version would work with it at least. To adhere to standards, drop the backslash there.)
These two sed commands do the exact same thing:
Code:
s|foo/bar|baz|g
s/foo\/bar/baz/g
The backslash is only necessary if the character would be interpreted differently otherwise.
Quote:
Originally Posted by contra04
also what is the $? character?
|
Each command has an
exit status code. If the command is successful, the status is 0. If the command fails, the status is nonzero.
$? is the status from the last command.
This also means that
Code:
some-command...
if [ $? -eq 0 ]; then
echo "Successful"
else
echo "Failed"
fi
if some-command... ; then
echo "Successful"
else
echo "Failed"
fi
both do and test the exact same thing: whether
some-command... exit status was zero/success or nonzero/error.
Additionally,
Code:
some-command...
if [ $? -ne 0 ]; then
exit $?
fi
if ! some-command... ; then
exit $?
fi
some-command... || exit $?
all three do the same thing: they run
some-command... and abort the script (using the same exit status as the command) if it failed, i.e. returned a non-zero exit status.
Quote:
Originally Posted by contra04
so far I have a mash up:
Code:
sed -e |interface Ethernet 0\/0.*|/a\Duplex Full|g r7.txt
any ideas on the syntax of this one? |
How about
Code:
-e '/^[\t\v\f\r ]*interface[\t\v\f\r ]/ a\\Duplex full'
This one matches any line that begins with optional whitespace, word "interface", and a whitespace character, and inserts "Duplex full" before the next line. The interface line itself is not edited, it is kept intact; it's just used to find the spot where to add the new line.
Note that you seem to be having some issues with proper quoting. I recommend you take a look at the
Quoting chapter in the
Bash Reference Manual; the first three subsections (Escape Character, Single Quotes, and Double Quotes) are the most important.
Most of the problems I've seen in shell scripts stem for incorrect/bad quoting. You really should learn it first, and apply it always. I recommend "defensive quoting", i.e. using the strictest form of quoting that will work, even when quoting might not be technically required, and it has served me extremely well.
The most basic rules are actually quite simple:
- Remember that the strings you write will be interpreted by the shell first. They're only given to the actual commands after the shell has applied its own magic first.
- Single quotes '...' tell the shell to keep the content intact, not apply its magic to the contents. The single quote characters themselves are not given to the command, but whatever is between them is.
- Double quotes "..." tell the shell to apply its magic to the contents, but keep the result as a single string, as a single parameter to the command.
The shell will interpret escapes like \" and variable references like $foo and so on.
Expressions "$@" and "${array[@]}" are exceptions to this rule. They expand the lists (positional parameters for the first, array items for the second) as individual parameters.
- Omitting quotes tells the shell to split the words into separate parameters.
Details depend on shell options, though.
- Quotes can be joined. "a"'b'cde"f" is the same as 'abcdef' and abcdef .
This is useful if you want to insert a variable into a complex string, such as a sed pattern.
'this is the fixed string part'"$variable"'the fixed string part continues' is a single string to the shell.
The magic that the shell applies in different situations is described in
Shell Expansions chapter in the Bash Reference Quide. It's a bit heavy chapter, but knowing the stuff in it does make script writing a whole lot easier. If you haven't found my replies too tedious to read, the chapters in the manual I've referred to here should be pretty easy to understand
