Hot answers tagged

17

That's because in <<< $line, bash does word splitting, (though not globbing) on $line as it's not quoted there and then joins the resulting words with the space character (and puts that in a temporary file followed by a newline character and makes that the stdin of cut). $ a=a,b,,c bash -c 'IFS=","; sed -n l <<< $a' a b c$ tab happens ...


13

What happens is that bash replaces the tabs with spaces. You can avoid this problem by saying "$line" instead, or by explicitly cutting on spaces.


13

Use the \ character to escape the * to make it a normal character. grep '^\*\*' test.out Also note the single quote ' and not double quote " to prevent the shell expanding things


9

The problem is that you're not quoting $line. To investigate, change the two scripts so they simply print $line: #!/usr/bin/env bash while read line; do echo $line done < "$1" and #!/usr/bin/env zsh while read line; do echo $line done < "$1" Now, compare their output: $ bash.sh input foo bar baz foo bar baz $ zsh.sh input foo bar ...


8

Once one is inside $(...), quoting starts all over from scratch. In other words, "..." and $(...) can nest within each other. Process substitution, $(...), can contain one or more complete double-quoted strings. Also, double-quoted strings may contain one or more complete process substitutions. But, they do not interlace. Thus, a double-quoted string ...


7

As you wanted to check the line which starts with ** and ends with ), you can combine two grep operation like this, grep '^*\*' test.out | grep ')$' Or with single grep command like this, grep -E '^\*\*.*\)$' test.out Explanation ^\*\* : match line which starts with ** .* : match everything after ** \)$ : match line which also has ) at the end of ...


4

Your puzzle isn't right about how bash (and the shell in general) parsed the input. In: DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" First, bash parse the right hand side of assignment to one long string $( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd ) because double quote can appear inside double quotes. After then, bash ...


3

It's not the shell None of the answers so far has touched on the real problem. It would be helpful to explain why it does not work as you expect. grep -i "^**" test.out Because you have quoted the pattern to grep, * is not expanded by the shell. It is passed to grep as-is. This is explained in the manual page[1] for bash[2]: Enclosing characters in ...


2

There's no need to escape it if you just want an exclamation mark in the prompt. PS1='foobar!' See what happens.


2

Other options. You can use sed or awk also $ sed -n '/^*\*/p' test.out $ awk '/^*\*/' test.out To know lines that end with ) use also grep or sed or awk $ grep ')$' test.out $ sed -n '/)$/p' test.out $ awk '/)$/' test.out


2

Instead of: cmd="cat ${file}" printf '%s\n' "Running command: '${cmd}'" ${cmd} Either pass a fixed command to eval for it to be interpreted as shell code. cmd='cat -- "$file"' printf '%s\n' "Running command: '${cmd}'" eval "$cmd" That will output Running command: cat -- "$file" which is probably not what you want. Or (bash specific) use printf %q to ...


2

[Inspired by this answer by cas.] But what if …? But what if my script sets a variable to a known value before using it?  In particular, what if it sets a variable to one of two or more possible values (but it always sets it to something known), and none of the values contain space or glob characters?  Isn’t it safe to use it without quotes in ...


1

As has already been answered, a more portable way to use a variable is to quote it: $ printf '%s\t%s\t%s\n' foo bar baz foo bar baz $ l="$(printf '%s\t%s\t%s\n' foo bar baz)" $ <<<$l sed -n l foo bar baz$ $ <<<"$l" sed -n l foo\tbar\tbaz$ There is a difference of implementation in bash, with the line: l="$(printf '%s\t%s\t%...


1

With #!/bin/bash set -f mono app.exe "$@" set -f has no effect because the double-quoted argument array ( "$@" ) undergoes no further expansions. If "$@" contains an argument whose value is *, it will get through to mono app.exe unchanged. The problem is, that the shell calling this wrapper script will want to expand the asterisk, as set +f is the ...


1

You have multiple levels of nested double-quotes. that gets very tricky, very ugly, and very difficult to read and modify. e.g. ` ssh ${OS_USER}@${OS_HOST} \ ". ~/.kshrc; ... ; echo \"export RC_DB_INSTANCE=\\\"\\\$7\\\"\" >> RC_CONV_SET_VARS". (NOTE: i tested that multi-quoted echo with bash -c on my system, and it worked with that but I'...



Only top voted, non community-wiki answers of a minimum length are eligible