I want to strip all numeric characters from a String variable, eg from:



> qwerty

I've searched many posts but they either use sed to output to file/file names, or output to echo. I was not able to get it working with because of the white space:

VARIABLE=$VARIABLE | sed 's/[0-9]*//g'

With bash:

$ printf '%s\n' "${VARIABLE//[[:digit:]]/}"

[:digit:] can contain other characters than 0 to 9 depend on your locale. If you want only to remove 0 to 9, use C locale instead.

  • 2
    Note: depending on your locale, [:digit:] might contain more or less than you would expect it to. If you only want the numbers 0 to 9, use LC_COLLATE=C and [0-9]. – Chris Down Nov 25 '15 at 11:05
  • 1
    @ChrisDown: Yes, the question asked for numeric characters, not 0 to 9, so I used [:digit:] instead of [0-9]. – cuonglm Nov 25 '15 at 12:00
  • Yeah, it's good for the question asked. It's not uncommon for Westerners to assume that [;digit:] == [0-9] though, so worth mentioning the pitfalls :-) – Chris Down Nov 25 '15 at 14:52

For variety, here's methods using


VARIABLE=$(printf '%s' "$VARIABLE" | tr -d '0123456789')


VARIABLE=$(printf '%s' "$VARIABLE" | sed 's/[0-9]//g')

Bash expansion, by far the most terse:


and finally Bash expansion again, this time using the [[:digit:]] character class.


Note that (as others have pointed out) [[:digit:]], should cover anything defined as a digit in your locale.

  • Where can I find docs for //.../? Is it a normal regex? I tried //[0-9]{2}\$/ for two numbers at the end, to no success. – Ondra Žižka Nov 2 '18 at 13:40
  • It's part of the bash variable expansion syntax, not Regexp. It means replace all matches. – ocodo Nov 2 '18 at 23:00
set -f # Disable glob
printf %s $VARIABLE


further manipulation is possible.

set -f # Disable glob
set -- $VARIABLE
printf "replaced $# numbers in \$VARIABLE. RESULT:\t%s\n" "$*"

replaced 6 numbers in $VARIABLE. RESULT:    qwerty
  • hmm, my variable becomes "qwe rty" with 3 spaces in the middle and 3 at the end – George Nov 25 '15 at 10:48
  • @George - you're probably using echo which replaces nulls with spaces - like eval. – mikeserv Nov 25 '15 at 10:49

White space (actually, failure to quote your variables) was only part of the problem.

You can't just pipe a variable through sed like that, it doesn't work. More precisely, it doesn't pipe the value of "$VARIABLE" through sed, the shell will try to execute the value of "$VARIABLE" and pipe the output of that through sed. BTW, this is not a bug - this is useful if $VARIABLE happens to contain a valid command like ls or rsync or whatever.

Also, if you want to assign the ouput of a command or pipeline to a variable, you need to surround that command/pipeline with $().

So, to modify a variable with sed, you need to do something like this:

VARIABLE=$(printf '%s' "$VARIABLE" | sed 's/[0-9]*//g')

You could use echo there instead of printf but echo will interpret and act on certain character sequences in $VARIABLE (e.g. \t, \n, \r, etc), while printf won't. You'll run across a lot of examples using echo...replace them with printf '%s', it's much safer.

  • Is there any real reason to single quote the %s ? – Wildcard Nov 25 '15 at 22:53
  • 1
    @wildcard. %s by itself, no. more complicated format strings should be quoted, though, so it's a good habit to get into. – cas Nov 25 '15 at 22:55
  • there was no failure to quote any variables - everything was quoted just fine. and white-space isn't even involved (and rarely actually is). i know the asker mentions it as a possible source of whatever the issue was, but it probably isn't helpful to encourage wrongful assumptions. your command substitution will strip white-space from the tail of whatever is in $VARIABLE, though. – mikeserv Nov 26 '15 at 3:25
  • and you're making that judgement on one made up example of VARIABLE=qwe123rty567? OK, right. I made my assessment ("failure to quote your variables") on the basis of none of the OP's examples having quotes around the variables, and the fact that he mentioned white-space as being a problem. – cas Nov 26 '15 at 4:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.