[SOLVED] Using Periods in Shell Script Variables

Woodsman · 11-20-2009, 10:34 PM

How does one work around not being able to use periods in shell script variables? In bash version 3.x?

I have some string data that actually is a number but does not need to be treated as a number, such as x.y.z. The variable can be treated as a string. I want to replace the string in a text file with sed or awk. The problem is not sed or awk but the periods.

Bash 3.x fumbles with periods in a variable.

Slackware 12.2, bash 3.1.017-2.

Thanks.

GrapefruiTgirl · 11-20-2009, 10:43 PM

Code:

root@reactor:/home/sasha# echo "12.34.56.78" | sed 's/34.56/HH.GG/'
12.HH.GG.78
root@reactor:/home/sasha# var="12.34.56.78"
root@reactor:/home/sasha# echo $var | sed 's/34.56/HH.GG/'
12.HH.GG.78
root@reactor:/home/sasha#

GNU bash, version 3.1.17(2)-release (x86_64-slackware-linux-gnu)

Woodsman, can you show us an example? I don't understand why the periods are giving you a hard time (maybe you need to escape them since they *can* be special chars?)

Sasha

tuxdev · 11-20-2009, 10:46 PM

You don't.

What do you *really* need to do that you think you need periods in a variable name? There's quite a few times I've itched for periods to be allowed in varnames myself, but the alternative has actually always been cleaner and more elegant than if that feature existed.

EDIT: or did I misunderstand the issue?

Woodsman · 11-20-2009, 11:35 PM

Quote:

I don't understand why the periods are giving you a hard time

The periods pose no problems when working directly in the command line. Only when running the same command in a script.

I can hard-code the text in the script and that works fine. For example, I can sed with 1.2.3 rather than $VARIABLE, which contains '1.2.3'. When I use $VARIABLE the script fails to perform the substitution.

Quote:

What do you *really* need to do that you think you need periods in a variable name?

I'm extracting text from a text file and the text contains the periods. I need to work with the periods.

larryhaja · 11-20-2009, 11:56 PM

Quote:

Originally Posted by Woodsman

I can hard-code the text in the script and that works fine. For example, I can sed with 1.2.3 rather than $VARIABLE, which contains '1.2.3'. When I use $VARIABLE the script fails to perform the substitution.

How are you performing the substitution with sed. For instance, are you using single or double quotes? Double quotes allow the value of the variable to be passed (or used) by sed where single quotes will give a direct substitution of $VARIABLE.

Woodsman · 11-20-2009, 11:59 PM

Quote:

How are you performing the substitution with sed. For instance, are you using single or double quotes?

Double. I had problems long ago with single quotes (check LQ for the thread) and learned to use double.

GrapefruiTgirl · 11-21-2009, 12:01 AM

OK, I made a file called "test" which contained a single line:

123.456.789

and I made a script as follows:

Code:

#!/bin/bash
var="123.456"
sed -i s/$var/hello.there/ test

and it worked. The file then contained:

hello.there.789

However, when the sed statements' guts were in single quotes as I usually would have, it did not work. It also didn't work with $var in double quotes.

Does this help, or am I out in left field?

Sasha

Woodsman · 11-21-2009, 12:50 AM

Sasha, you helped in a subtle indirect way.

I decided to perform the same exercise as you. I created a text file and a new script. Worked as expected.

I then slowly expanded the new script with snippets from the problematic script. Everything kept working as expected.

Serious head scratching time.

I don't know what finally motivated me to check, but somewhere in the deep chasms of my mind I decided to check the end-of-line usage in the several text files I was extracting and modifying text. Okay, you probably can guess the remainder of the story now.

The text files all used Windows/DOS end-of-line terminations rather than 'nix.

I manually changed the text files to 'nix style and then my problematic script no longer was problematic. The inline modifications with sed worked as expected.

So in the original script I converted the end-of-line usage on-the-fly with the fromdos command.

My script now works like I intended several hours ago.

Who would have guessed?

What an awful way to spend several hours!

GrapefruiTgirl · 11-21-2009, 08:32 AM

Jeez, the line endings *would* be a stumbler indeed. Very tricky.

Glad you got it figured

Sasha