I have a line in a script that works in zsh but does not work in bash:
SHORTDIR=${${${PWD##*/}//./_dot_}//:/_colon_}
This is basically a short/efficient version of basename $PWD | sed -e 's/\./0/g' -e 's/:/1/g'.
What's the syntax for stringing together variable expansions?
Sadly, the first part of the substitution has to be a parameter name. An alternative sed version would be:
echo $PWD | sed -e 's!.*/!!' -e 'y/.:/01/'
I was hoping that there'd be a better way than
SHORTDIR=${PWD##*/}
SHORTDIR=${SHORTDIR//./_dot_}
SHORTDIR=${SHORTDIR//:/_colon_}
but this is what I'm sticking to.
According to the answers to the question linked by #perreal, bash basically does not allow for expanded variables themselves as a "parameter" and that's why it fails.
Just to throw this out there, many people don't know that multiple assignments can be done in one line. E.g.:
$ a=1234 a=${a:0:3} a=${a/1}
or
SHORTDIR=${PWD##*/} SHORTDIR=${SHORTDIR//./_dot_} SHORTDIR=${SHORTDIR//:/_colon_}
Related
I'm trying below
a = device.1.2
echo $a should print 1.2
Tried with sed 's/[a-z]//g' a
First thing first please make sure your shell variable doesn't have space while assigning value to it, so have it like this: a="device.1.2". With your shown samples, could you please try following once.
Have it with parameter substitution way: Where we need not to use an external program to get the value.
echo "${a#*.}"
OR with sed: Since OP was trying sed so adding one sed solution here, this nice command was given by Benjamin see comments for same.
echo "$a" | sed 's/^[^.]*\.//'
I'm trying to use enscript to print PDFs from Mutt, and hitting character encoding issues. One way around them seems to be to just use sed to replace the problem characters: sed -ir 's/[“”]/"/g' {input}
My test input file is this:
“very dirty”
we’re
I'm hoping to get "very dirty" and we're but instead I'm still getting
â\200\234very dirtyâ\200\235
weâ\200\231re
I found a nice little post on printing to PDFs from Mutt that I used as a starting point. I have a bash script that I point to from my .muttrc with set print_command="$HOME/.mutt/print.sh" -- the script currently reads about like this:
#!/bin/bash
input="$1" pdir="$HOME/Desktop" open_pdf=evince
# Straighten out curly quotes
sed -ir 's/[“”]/"/g' $input
sed -ir "s/[’]/'/g" $input
tmpfile="`mktemp $pdir/mutt_XXXXXXXX.pdf`"
enscript --font=Courier8 $input -2r --word-wrap --fancy-header=mutt -p - 2>/dev/null | ps2pdf - $tmpfile
$open_pdf $tmpfile >/dev/null 2>&1 &
sleep 1
rm $tmpfile
It does a fine job of creating a PDF (and works fine if you give it a file as an argument) but I can't figure out how to fix the curly quotes.
I've tried a bunch of variations on the sed line:
input=sed -r 's/[“”]/"/g' $input
$input=sed -ir "s/[’]/'/g" $input
Per the suggestion at Can I use sed to manipulate a variable in bash? I also tried input=$(sed -r 's/[“”]/"/g' <<< $input) and I get an error: "Syntax error: redirection unexpected"
But none manages to actually change $input -- what is the correct syntax to change $input with sed?
Note: I accepted an answer that resolved the question I asked, but as you can see from the comments there are a couple of other issues here. enscript is taking in a whole file as a variable, not just the text of the file. So trying to tweak the text inside the file is going to take a few extra steps. I'm still learning.
On Editing Variables In General
BashFAQ #21 is a comprehensive reference on performing search-and-replace operations in bash, including within variables, and is thus recommended reading. On this particular case:
Use the shell's native string manipulation instead; this is far higher performance than forking off a subshell, launching an external process inside it, and reading that external process's output. BashFAQ #100 covers this topic in detail, and is well worth reading.
Depending on your version of bash and configured locale, it might be possible to use a bracket expression (ie. [“”], as your original code did). However, the most portable thing is to treat “ and ” separately, which will work even without multi-byte character support available.
input='“hello ’cruel’ world”'
input=${input//'“'/'"'}
input=${input//'”'/'"'}
input=${input//'’'/"'"}
printf '%s\n' "$input"
...correctly outputs:
"hello 'cruel' world"
On Using sed
To provide a literal answer -- you almost had a working sed-based approach in your question.
input=$(sed -r 's/[“”]/"/g' <<<"$input")
...adds the missing syntactic double quotes around the parameter expansion of $input, ensuring that it's treated as a single token regardless of how it might be string-split or glob-expanded.
But All That May Not Help...
The below is mentioned because your test script is manipulating content passed on the command line; if that's not the case in production, you can probably disregard the below.
If your script is invoked as ./yourscript “hello * ’cruel’ * world”, then information about exactly what the user entered is lost before the script is started, and nothing you can do here will fix that.
This is because $1, in that scenario, will only contain “hello; ’cruel’ and world” are in their own argv locations, and the *s will have been replaced with lists of files in the current directory (each such file substituted as a separate argument) before the script was even started. Because the shell responsible for parsing the user's command line (which is not the same shell running your script!) did not recognize the quotes as valid at the time when it ran this parsing, by the time the script is running, there's nothing you can do to recover the original data.
Abstract: The way to use sed to change a variable is explored, but what you really need is a way to use and edit a file. It is covered ahead.
Sed
The (two) sed line(s) could be solved with this (note that -i is not used, it is not a file but a value):
input='“very dirty”
we’re'
sed 's/[“”]/\"/g;s/’/'\''/g' <<<"$input"
But it should be faster (for small strings) to use the internals of the shell:
input='“very dirty”
we’re'
input=${input//[“”]/\"}
input=${input//[’]/\'}
printf '%s\n' "$input"
$1
But there is an underlying problem with your script, you are trying to clean an input received from the command line. You are using $1 as the source of the string. Once somebody writes:
./script “very dirty”
we’re
That input is lost. It is broken into shell's tokens and "$1" will be “very only.
But I do not believe that is what you really have.
file
However, you are also saying that the input comes from a file. If that is the case, then read it in with:
input="$(<infile)" # not $1
sed 's/[“”]/\"/g;s/’/'\''/g' <<<"$input"
Or, if you don't mind to edit (change) the file, do this instead:
sed -i 's/[“”]/\"/g;s/’/'\''/g' infile
input="$(<infile)"
Or, if you are clear and certain that what is being given to the script is a filename, like:
./script infile
You can use:
infile="$1"
sed -i 's/[“”]/\"/g;s/’/'\''/g' "$infile"
input="$(<"$infile")"
Other comments:
Then:
Quote your variables.
Do not use the very old `…` syntax, use $(…) instead.
Do not use variables in UPPER case, those are reserved for environment variables.
And (unless you actually meant sh) use a shebang (first line) that targets bash.
The command enscript most definitively requires a file, not a variable.
Maybe you should use evince to open the PS file, there is no need of the step to make a pdf, unless you know you really need it.
I believe that is better use a file to store the output of enscript and ps2pdf.
Do not hide the errors printed by the commands until everything is working as desired, then, just call the script as:
./script infile 2>/dev/null
Or as required to make it less verbose.
Final script.
If you call the script with the name of the file that enscript is going to use, something like:
./script infile
Then, the whole script will look like this (runs both in bash or sh):
#!/usr/bin/env bash
Usage(){ echo "$0; This script require a source file"; exit 1; }
[ $# -lt 1 ] && Usage
[ ! -e $1 ] && Usage
infile="$1"
pdir="$HOME/Desktop"
open_pdf=evince
# Straighten out curly quotes
sed -i 's/[“”]/\"/g;s/’/'\''/g' "$infile"
tmpfile="$(mktemp "$pdir"/mutt_XXXXXXXX.pdf)"
outfile="${tmpfile%.*}.ps"
enscript --font=Courier10 "$infile" -2r \
--word-wrap --fancy-header=mutt -p "$outfile"
ps2pdf "$outfile" "$tmpfile"
"$open_pdf" "$tmpfile" >/dev/null 2>&1 &
sleep 5
rm "$tmpfile" "$outfile"
I am reading some other developer script and I run across something I dont quite understand. Please help
typeset -u DOC_RET_CODE=`grep ^${PRNT_JOB_NAME}${SEQ_NUM} ${INPUT_FILE} |cut -c273-276`
if [ "${DOC_RET_CODE}" = "GOOD" ]
I look up typeset - u and it seems like it generate read-only variable, but not sure what it doing there. For grep, I usually pipe an input like ls | grep test, but grep by itself like this, I am not so sure. I know cut -c273-276, but 4 characters out from position 273-276. So what exactly does this script do?
The back-tick command (which would be better enclosed in $(...)) is grepping for a line starting with the print job name and sequence number from the input file, and then the 'cut' command is collecting columns 273-276 (4 characters). The upper-case version of this value (typeset -u) is assigned to $DOC_RET_CODE. The test line checks whether the document return code is GOOD and does something (not shown) if it is ... and maybe something else if the status is not good.
> help typeset
typeset: typeset [-aAfFgilrtux] [-p] name[=value] ...
Set variable values and attributes.
Obsolete. See `help declare'.
> help declare
declare: declare [-aAfFgilrtux] [-p] [name[=value] ...]
Set variable values and attributes.
…
Options which set attributes:
-u to convert NAMEs to upper case on assignment
In other words, this is making everything (the result of the grep|cut pipe) uppercase to avoid a tr a-z A-Z and allow a simple comparison against GOOD.
For your other question, grep is being run against a filename ${INPUT_FILE}. You can run that command as is (after manually substituting the variables)
It's not by itself; it's passed the argument ${INPUT_FILE}, and it will read that file instead of its standard input. The "useless use of cat" version would be cat ${INPUT_FILE} | grep ....
Note that, per the earlier answer, bash has decided to drop compatibility and deprecate typeset. typeset is largely compatible between ksh, bash, and zsh.
I'm new to bash scripts (and the *nix shell altogether) but I'm trying to write this script to make grepping a codebase easier.
I have written this
#!/bin/bash
args=("$#");
for arg in args
grep arg * */* */*/* */*/*/* */*/*/*/*;
done
when I try to run it, this is what happens:
~/Work/richmond $ ./f.sh "\$_REQUEST\['a'\]"
./f.sh: line 4: syntax error near unexpected token `grep'
./f.sh: line 4: ` grep arg * */* */*/* */*/*/* */*/*/*/*;'
~/Work/richmond $
How do I do this properly?
And, I think a more important question is, how can I make grep recurse through subdirectories properly like this?
Any other tips and/or pitfalls with shell scripting and using bash in general would also be appreciated.
The syntax error is because you're missing do. As for searching recursively if your grep has the -R option you would do:
#!/bin/bash
for arg in "$#"; do
grep -R "$arg" *
done
Otherwise you could use find:
#!/bin/bash
for arg in "$#"; do
find . -exec grep "$arg" {} +
done
In the latter example, find will execute grep and replace the {} braces with the file names it finds, starting in the current directory ..
(Notice that I also changed arg to "$arg". You need the dollar sign to get the variable's value, and the quotes tell the shell to treat its value as one big word, even if $arg contains spaces or newlines.)
On recusive grepping:
Depending on your grep version, you can pass -R to your grep command to have it search Recursively (in subdirectories).
The best solution is stated above, but try putting your statement in back ticks:
`grep ...`
You should use 'find' plus 'xargs' to do the file searching.
for arg in "$#"
do
find . -type f -print0 | xargs -0 grep "$arg" /dev/null
done
The '-print0' and '-0' options assume you're using GNU grep and ensure that the script works even if there are spaces or other unexpected characters in your path names. Using xargs like this is more efficient than having find execute it for each file; the /dev/null appears in the argument list so grep always reports the name of the file containing the match.
You might decide to simplify life - perhaps - by combining all the searches into one using either egrep or grep -E. An optimization would be to capture the output from find once and then feed that to xargs on each iteration.
Have a look at the findrepo script which may give you some pointers
If you just want a better grep and don't want to do anything yourself, use ack, which you can get at http://betterthangrep.com/.
To clarify, I am looking for a way to perform a global search and replace on the previous command used. ^word^replacement^ only seems to replace the first match.
Is there some set option that is eluding me?
Try this:
$ echo oneone
oneone
$ !!:gs/one/two/ # Repeats last command; substitutes 'one' --> 'two'.
twotwo
This solution uses Bash Substring Replacement:
$ SENTENCE="1 word, 2 words";echo "${SENTENCE//word/replacement}"
1 replacement, 2 replacements
Note the use of the double slashes denotes "global" string replacement.
This solution can be executed in one line.
Here's how to globally replace a string in a file named "myfile.txt":
$ sed -i -e "s/word/replacement/g" myfile.txt
Blending my answer here with John Feminella's you can do this if you want an alias:
$alias dothis='`history -p "!?monkey?:gs/jpg/png/"`'
$ls *.jpg
monkey.jpg
$dothis
monkey.png
The !! only does the previous command, while !?string? matches the most recent command containing "string".
A nasty way to get around this could be something like this:
Want to echo BAABAA rather than BLABLA by swapping L's for A's
$ echo "BLABLA"
BLABLA
$ `echo "!!" | sed 's/L/A/g'`
$(echo "echo "BLABLA" " | sed 's/L/A/g')
BAABAA
$
Unfortunately this technique doesn't seem to work in functions or aliases.
this question has many dupes and one elegant answer only appears in this answer of user #Mikel in unix se
fc -s pat=rep
this bash builtin is documented under the chapter 9.2 Bash History Builtins
In the second form, command is re-executed after each instance of pat
in the selected command is replaced by rep. command is interpreted the
same as first above.
A useful alias to use with the fc command is r='fc -s', so that typing
‘r cc’ runs the last command beginning with cc and typing ‘r’
re-executes the last command (see Aliases).
I test it on SUSE 10.1.
"^word^replacement^" doesn't work, while "^word^replacement" works well.
for a instance:
linux-geek:/home/Myworks # ls /etc/ld.so.conf
/etc/ld.so.conf
linux-geek:/home/Myworks # ^ls^cat
cat /etc/ld.so.conf
/usr/X11R6/lib/Xaw3d
/usr/X11R6/lib
/usr/i486-linux-libc5/lib=libc5
/usr/i386-suse-linux/lib
/usr/local/lib
/opt/kde3/lib
/opt/gnome/lib
include /etc/ld.so.conf.d/*.conf
linux-geek:/home/Myworks #