Tag Info

New answers tagged

-2

As far as I know, there are only two cases in which it is necessary to double-quote expansions, and those cases involve the two special shell parameters "$@" and "$*" - which are specified to expand differently when enclosed in double-quotes. In all other cases (exluding, perhaps, shell-specific array implementations) the behavior of an expansion is a ...


1

$'\n' is basically the same as typing Enter. So in your Perl example, it turns into* if(/ab cd/) Which isn't what you wanted. Reasons I can think of to use $'...': You want to put a single quote inside a single-quote delimited string, e.g. logger $'Can\'t open file' To make non-printable characters clearer, e.g. $'a\tb' rather than 'a<TAB ...


1

You use $'...' when you want escape sequences to be interpreted by the shell. $ echo 'a\nb' a\nb $ echo $'a\nb' a b In perl, -e option get a string. If you use $'...', the escape sequences in string are interpreted before passing to perl. In your case, \r had gone and never passed to perl. With $'...': $ perl -MO=Deparse -w -e $'binmode STDIN;undef ...


0

If you do: eval "$name=\$val" ...and $name contains a ; - or any of several other tokens the shell might interpret as delimiting a simple command - preceded by proper shell syntax, that will be executed. name='echo hi;varname' val='be careful with eval' eval "$name=\$val" && echo "$varname" OUTPUT hi be careful with eval You can do: eval ...


3

A good way to work with eval is to replace it with echo for testing. echo and eval work the same (if we set aside the \x expansion done by some echo implementations like bash's under some conditions). Both commands join their arguments with one space in between. The difference is that echo displays the result while eval evaluates/interprets as shell code ...


9

Don't use eval for this; use declare. var_name="fruit" var_value="blue orange" declare "$var_name=$var_value" Note that word-splitting is not an issue, because everything following the = is treated as the value by declare, not just the first word. In bash 4.3, named references make this a little simpler. $ declare -n var_name=fruit $ var_name="blue ...


9

Don't use eval, use declare $ declare "$var_name=$var_value" $ echo "fruit: >$fruit<" fruit: >blue orange<


2

In addition to @Michael Homer's answer, you can use bash eval function: PARMS='-rvu' PARMS+=" --delete --exclude='.git'" echo "$PARMS" eval "rsync ${PARMS} . "'"${TARGET}"'


12

There is a difference between: PARMS+="... --exclude='.git'" and ... --exclude='.git' In the first, the single quotes are inside quotes themselves, so they are literally present in the substituted text given to rsync as arguments. rsync gets an argument whose value is --exclude='.git'. In the second, the single quotes are interpreted by the shell at ...


5

By default, scp remote paths are interpreted relative to the home directory, so you don't need the ~ at all: scp user@remote.host.com:some/file/name filename will download some/file/name from the home directory of user and save it as filename locally. When you want to use an absolute file path on the remote server, start it with /: scp host:/etc/passwd ...


6

You need to use single quotes instead of double quotes to prevent shell expansion before your command is passed to a remote server. BTW, $( are now preferred over ` in command substitution. Unless you use shell that only supports ` consider using $( in command substitution. See here for more details.


0

( scale=${scale##*[!0-9]*} : ${scale:?input must be an integer} ) || exit That does the check and outputs your error.


0

command="grep $regex1 filelist | grep $regex2" echo $command | bash


2

Remove quotes if ! [[ "$scale" =~ ^[0-9]+$ ]]


2

Use -eq operator of test command: read scale if ! [ "$scale" -eq "$scale" ] 2> /dev/null then echo "Sorry integers only" fi It not only works in bash but also any POSIX shell. From POSIX test documentation: n1 -eq n2 True if the integers n1 and n2 are algebraically equal; otherwise, false.


3

You need to escape the percent characters using a backslash: .../SK_ITEM_EXTRACT_MFGPRO_$(date +\%m\%d\%y).txt From the crontab(5) man page from the ISC implementation of cron: The ``sixth'' field (the rest of the line) specifies the command to be run. The entire command portion of the line, up to a newline or % character, will be executed by /bin/sh ...


1

It's the backslash. Backslash defuses the next character and makes it lose special meanings. The sed command is reading what you've typed as (just the sed expression here, I'm not doing the whole tedious shell command line): s <SPACE> C : Literal <SPACE> /root/ <SPACE> You've told sed that you want to use as the marker for the ...


4

Where you use: sed -i 's C:\ /root/ g' you're using the s command with a space character separating the different parts of the command, which is unusual, but completely valid. When you precede your separator character with a backslash, though, it's not treated as a separator, but as part of the argument itself. The problem you have here is that the ...



Top 50 recent answers are included