bizarre shell problem

Posted by: ukengb

bizarre shell problem - 16/03/2005 19:43

I have a script that includes the following line:-

[ ${@:0-2:1} = '.' ] || echo

but after displaying the text I get

Segmentation fault

If I run the same code on the command line I don't get the error.

If I change the substr code in the script to

${@:0-2}

it's OK - no error, but of course isn't doing what I want.
So what can be the problem that causes the error only when in a shell script, but not otherwise?

Come to think of it, what's a segmentation fault?
Posted by: mlord

Re: bizarre shell problem - 16/03/2005 21:08

Quote:
Come to think of it, what's a segmentation fault?


Bad pointer. You have found a bug in whatever shell you're using.
Report it, or it may never get fixed.

Cheers
Posted by: mlord

Re: bizarre shell problem - 16/03/2005 21:13

What shell is that for, anyway? Bash doesn't like it as-is.
But bash does accept this version:

[ ! ! "${@:2:1}" = "." ] || echo

Cheers
Posted by: tfabris

Re: bizarre shell problem - 16/03/2005 22:22

Quote:
You have found a bug in whatever shell you're using.
Report it, or it may never get fixed.

Isn't he talking about Bash in the empeg developer build? So who does he report it to?
Posted by: mlord

Re: bizarre shell problem - 16/03/2005 23:14

Quote:
Isn't he talking about Bash in the empeg developer build? So who does he report it to?


He didn't say which shell, or platform.

But if it is the player build, then.. no point in reporting it, unless he can also get it to do it on a more modern machine!

Cheers
Posted by: ukengb

Re: bizarre shell problem - 17/03/2005 09:50

Quote:
Quote:
Isn't he talking about Bash in the empeg developer build? So who does he report it to?


He didn't say which shell, or platform.

But if it is the player build, then.. no point in reporting it, unless he can also get it to do it on a more modern machine!


'He' didn't indicate where this problem was occurring - sorry. I was convinced I had stated this was a script running on the empeg. Anyway, that's where it is and of course it's bash.

The modified code that Mark (Lord) posted probably does work, but it's not what I need. I want to check that the penultimate char is a period, but Mark's code checks the second char. The reason I use '0-1' is that I have found in the past that bash will not accept a negative value when you want to represent that no. of chars from the end of the string, BUT if you use that calculation it does work and indeed that appeared to be the case on the empeg. But as I then discovered, it works when you use the code on the command line, but causes this error when used in a script.

On my RedHat machine I have used these constructs without any problem (once I worked around the negative value problem), so it must be to do with the empeg's bash.

From what you all say it would appear that there's no way around this so I just have to modufy the code and my requirements to work around it. Would that be a fair assessment?
Posted by: wfaulk

Re: bizarre shell problem - 17/03/2005 12:52

ISTR that if the first line of your shell is "#!/bin/sh" then bash falls back to some sort of Bourne pseudo-compatibility. If you've got that in there, then try changing it to "#!/bin/bash".

This is just a guess, though.
Posted by: mlord

Re: bizarre shell problem - 17/03/2005 13:29

I take it you want code to detect the final character of the final arg, and tell whether it was a period or not?
Code:

#!/bin/bash
all="$@"
if [ "${all##*.}" = "" ]; then
echo "ended with a dot"
else
echo "did not end with a dot"
fi

Posted by: wfaulk

Re: bizarre shell problem - 17/03/2005 13:57

He states quite clearly:

Quote:
I want to check that the penultimate char is a period
Posted by: mlord

Re: bizarre shell problem - 17/03/2005 14:41

Quote:
He states quite clearly:

Quote:
I want to check that the penultimate char is a period



Oh.. dictionary out.. second last character.

Okay, so what he was doing originally should work, so long as his script ensures there are always at least two characters in the string.
Code:

junk=" $@"
[ "${junk:0-2:1}" = "." ] || echo no

Posted by: wfaulk

Re: bizarre shell problem - 17/03/2005 15:16

Hmm. I wonder if that's the problem -- that his test case had less than two characters. Reading past the end of an array would be a common cause for a seg fault and I can believe that there was a version of bash that failed to check for the front end of the array. Seems unlikely, but possible, especially if there was a different bug that failed to put the right thing in the variable being checked.
Posted by: ukengb

Re: bizarre shell problem - 17/03/2005 17:18

Quote:
Hmm. I wonder if that's the problem -- that his test case had less than two characters.

No, the test string was about 20 chars so no problem there. Actually I'm not sure if that would be a problem anyway, but in any case not applicable here.

I think the important point here is that the code I used only fails when used in a script, whereas there is NO error when used directly on the command line (nor on my RedHat machine in any circumstances). This is the puzzle, that there is a totally different result when using these 2 methods.

As I said, I'm resigned to figuring a 'get around' as I doubt the empeg bash will get upgraded, but thanks for the support anyway.
Posted by: mlord

Re: bizarre shell problem - 17/03/2005 22:27

The last version I posted here runs correctly from a script on my empeg player.

Cheers
Posted by: ukengb

Re: bizarre shell problem - 18/03/2005 06:27

OK, I've already re-written my script so that the error doesn't occur, but in the interests of our quest for knowledge and truth, I've doen some more checking:-)

My original line was

[ "${@:0-2:1}" = "." ] || echo

and this causes the seg. fault - always. But if I replace this with:-

anyvarname="$@"
[ "${anyvarname:0-2:1}" = "." ] || echo

there is no error. IOW the problem only relates to when $@ is used and seems to confirm the existence of a bash internal bug.

It's no longer a problem for me, but interesting to know what not to do in the future.
Posted by: ukengb

Re: bizarre shell problem - 18/03/2005 11:11

A quick question for Mark.

Hijack seems to eliminate multiple spacing from text strings before displaying them in a popup, am I right about this, or is there some other reason why my double spaces are not appearing in the displayed popup message?
Posted by: mlord

Re: bizarre shell problem - 18/03/2005 12:23

Quote:

Hijack seems to eliminate multiple spacing from text strings before displaying them in a popup ..?


Nope. Spaces are displayed as three columns of blank pixels each.

Try this, to help understand what is probably confusing you:
Code:

ftp to your player, and then do:

site popup 5 testing 123

site popup 5 "testing 123"



cheers
Posted by: mlord

Re: bizarre shell problem - 18/03/2005 12:26

Quote:

[ "${@:0-2:1}" = "." ] || echo

and this causes the seg. fault - always. But if I replace this with:-

anyvarname="$@"
[ "${anyvarname:0-2:1}" = "." ] || echo

there is no error


Actually, I was suprised that "${@ ... ]" works at all!

I suppose in the version of bash on the player, the coders may not have anticipated that anyone would even try it, since $@ means something quite different from "$@" or $*.

Cheers