[SOLVED] extracting floating numbers from variable using bash's builtin string chopping

ntubski · 07-17-2009, 01:20 PM

Quote:

Originally Posted by catkin

I set it in the shell initialisation; why not?

There could be a small annoyance if you send a script to someone else, your script will assume extglob is set, and it won't work with the default settings.

Quote:

My own scripting idiom is

Code:

oIFS="$IFS"
IFS="<whatever>"
<commands>
IFS="$oIFS"

Too bad bash doesn't have something like Lisp's let, then you could do

Code:

let IFS="<whatever>"
  <commands>
end
# IFS is restored

catkin · 07-17-2009, 04:03 PM

Quote:

Originally Posted by ntubski

There could be a small annoyance if you send a script to someone else, your script will assume extglob is set, and it won't work with the default settings.

Good point; thanks

Quote:

Originally Posted by ntubski

Too bad bash doesn't have something like Lisp's let, then you could do

Code:

let IFS="<whatever>"
  <commands>
end
# IFS is restored

The closest we get is the illegible and inefficient

Code:

eval $( IFS=<whatever>; <do something using new $IFS>; echo <statements for the parent shell to execute>)

David the H. · 07-17-2009, 04:50 PM

Quote:

Originally Posted by ghostdog74

an example might be more clear in what you are trying to explain. i am an english idiot.

What's so hard to understand? I'm simply pointing out that the "set --" command clears all previous positionals before creating new positionals with the new values. If later parts of your script rely on the previous values, they will break.

Quote:

#!/bin/bash

echo -----
echo $1
echo $2
echo $3
echo $4
echo -----

IFS="-"
a="C9-1.4-1.6"
set -- $a

echo -----
echo $1
echo $2
echo $3
echo $4
echo ------

david:[~]$ ./test.sh Fry Bender Leela Nibbler
-----
Fry
Bender
Leela
Nibbler
-----
-----
C9
1.4
1.6

------

All the previous values are lost, even the unused $4. That's ok if you don't need them anymore, but what if you do?

David the H. · 07-17-2009, 05:07 PM

As for using "unset" on IFS, I was just playing with this a day or two ago. I'm not sure what's going on with it exactly. The bash man page is unclear on what happens, and whether it returns it to the default value or not. But I ran some tests and it does seem to return to the default <space><tab><newline> behavior. I can't be perfectly sure it returns to the exact same state as before however.

ghostdog74 · 07-17-2009, 05:48 PM

Quote:

Originally Posted by David the H.

That's ok if you don't need them anymore, but what if you do?

you just have to save them if you want to use them later

Code:

echo -----
echo $1
echo $2
echo $3
echo $4
echo -----
save=("$@")
IFS="-"
a="C9-1.4-1.6"n
set -- $a

echo -----
echo $1
echo $2
echo $3
echo $4
echo ------
# 
unset IFS
set -- "${save[@]}"
echo -----
echo $1
echo $2
echo $3
echo $4
echo -----

Hence the reason why i can't understand why you say positional parameters are being lost (as in lost and can't be retrieved)

David the H. · 07-17-2009, 06:09 PM

Sigh.

I never said that it couldn't be worked around; only that it's something that you need to be aware of. You can't just drop it into an existing script without there being possible ramifications. It's not the "cleanest" solution to the original request.

Besides, it also forces it farther and farther away from the "simple" one-liner, if you need to go to all that trouble to save the old positions.

ghostdog74 · 07-17-2009, 07:31 PM

Quote:

Originally Posted by David the H.

Sigh.

I never said that it couldn't be worked around; only that it's something that you need to be aware of. You can't just drop it into an existing script without there being possible ramifications. It's not the "cleanest" solution to the original request.

Besides, it also forces it farther and farther away from the "simple" one-liner, if you need to go to all that trouble to save the old positions.

well, if OP wants to learn bash, then he has to take note of these. For myself, i wouldn't even bother with bash when it comes to parsing text/files

Code:

awk 'BEGIN{ string="C9-1.4-1.6"; split(string, s,"-");print s[1]}'

catkin · 07-18-2009, 02:21 AM

Quote:

Originally Posted by David the H.

As for using "unset" on IFS, I was just playing with this a day or two ago. I'm not sure what's going on with it exactly. The bash man page is unclear on what happens, and whether it returns it to the default value or not. But I ran some tests and it does seem to return to the default <space><tab><newline> behavior. I can't be perfectly sure it returns to the exact same state as before however.

If IFS is unset then a lot of Bash behaves as if IFS had the default value of <space><tab><newline> so many tests are inconclusive about what IFS contains.

Code:

c@CW8:~$ echo -n "$IFS" | od -x
0000000 0920 000a
0000003
c@CW8:~$ unset IFS
c@CW8:~$ echo -n "$IFS" | od -x
0000000
c@CW8:~$

That's a little obfuscated by endian and padding effects but it take it that 0920 000a (<tab><space><null><newline>) actually denotes <space><tab><newline>

David the H. · 07-19-2009, 08:27 AM

Quote:

Originally Posted by ghostdog74

well, if OP wants to learn bash, then he has to take note of these.

Which is exactly the reason I mentioned it. I was just trying to point out a possible "gotcha" that inexperienced bashers may not realize. I didn't intend for this to turn into a big debate or anything.

But as for "never using bash for text parsing", well, if all you need is to extract a short substring from a variable, then that's usually exactly what you do want to do. In most cases, using a bash built-in is more efficient than calling on an external tool like awk or sed. It's only when the text parsing becomes too complex to do quickly and easily in bash that calling on another tool becomes the better choice.

@catkin: Well, if bash generally behaves the same when IFS is unset as if it were the default, is there any situation in which unsetting it would cause problems? I suppose it would matter if you needed to specifically test for existence of one of the values, but would there be any serious effects otherwise?

catkin · 07-19-2009, 09:13 AM

Quote:

Originally Posted by David the H.

@catkin: Well, if bash generally behaves the same when IFS is unset as if it were the default, is there any situation in which unsetting it would cause problems? I suppose it would matter if you needed to specifically test for existence of one of the values, but would there be any serious effects otherwise?

Default and unset IFS are functionally identical according to the Open Group's (POSIX) shell definition. GNU's bash reference is not explicit but its section on differences in POSIX mode says nothing about IFS so presumably the default behaviour conforms with POSIX.

I'm going to try it and see if anything breaks.

EDIT:

Clarification: unset is not the same as empty (which is the same as null). Once a variable has been set it can only be unset using the unset command, according to The GNU Bash Reference Manual.