In bash, I thought that the only characters that retained their meta-character status inside double quotes were the dollar sign ($), the back-tick (`) and the backslash (\). Yet I get this:
After that, hitting the 'up' arrow does not retrieve the echo "Exclamation!" command, but the one issued before it. Obviously, something is going on with the bash history function, but it shouldn't be. You'd think that the double quotes would protect the exclamation from being interpreted as a meta-character.

It even happens with an example from the Bash Beginners Guide (http://www.tldp.org/LDP/Bash-Beginne...ect_03_03.html section 3.3.4:
whereas the Guide says that it should result in:

I'd say: "Go for it!"

Does anyone know what's going on here?

This is with bash version: 3.00.16(1)-release (SuSE 10.0). The same behaviour is observed in openSUSE 10.2 (bash version 3.1.17(1)-release) and Knoppix 5.1.1 2007-01-04 (bash version 3.1.17(1)-release).

Try this:
worked for me, without quotes. Dunno if it's echo-specific (shouldn't be though), but it seems it works

Thanks b0uncer, that's very interesting; though it's the opposite of what you'd expect.

It doesn't help me though. In a bash script, I was trying to evaluate the output of the pppoe-start command. When it connects successfully, it outputs to stdout Connected!. My script was falling over trying to process the variable that received the connection result. In the end, I had to hack the pppoe-start script and remove the offending ! character so that my script could evaluate whether the connection succeeded.

I can't explain what's happening with 'echo' (it's the same whether the builtin or /bin/echo). If you enter:you get:So it seems that regardless of the double quotes, bash is being triggered by the exclamation mark to look to the history function.

From the example given in the Bash Beginners Guide, I'd say it used to work as they explain, but that something has changed in the meantime. It seems that we can add the exclamation mark as a meta-character that retains its special meaning within double quotes.

Ok, try these too:
You can post that evaluation part of your script; hopefully there will be some other ways?

Thanks omnio, your examples have prompted me to look at how I was trying to develop my script. The script looks like this:Instead of actually running my 'pppoe-start' command (which would have needed 'pppoe-stop' to have been run beforehand), I wanted to check the accuracy of the 'sed' instruction by simulating that output of 'pppoe-start' by an echo statement directly in the bash shell. This is what I entered:which resulted in the error messages mentioned in my previous posts.

If I entered:I got a Null output, which is what I expected. I then hacked 'pppoe-start' to remove the exclamation character as a quick way of achieving what I wanted.

On reading your post, I decided to investigate this further. I could see that 'pppoe-start' had no difficulty outputting the exclamation character, so instead of using the 'echo' command in my test, I created this small script called 'pppoe-connected':and used the following as the test directly in the bash shell:This worked, which means that I can now go back to my 'pppoe-start' script and put the exclamation character back in.

It also means that the problem I experienced was not with the script I was developing, but with the method of testing in an interactive shell, which behaviour differs from that of a non-interactive shell that the scripts run in. I still think that the behaviour in the interactive shell is a bug, as it doesn't obey the rules specifying which special characters are protected by double quotes. It also used to behave according to the rules in the past, which also points to some recently introduced bug. Also, in the interactive shell, the exclamation character is only supposed to have special character status to invoke the history function when it's the first character on the line. But if you enter:the familiar error is produced. Two things are happening here. Firstly, the double quotes, far from protecting the exclamation character from shell interpretation, actually turn it into its metacharacter form. It should behave identically to your example:where the single quotes do protect the exclamation character.

Secondly, the text appearing before the exclamation character is being ignored, as if the exclamation character is the first one in the line, which sends bash on a search for a command from the history function. I assume this is a bug, which I will report to the bash developers.

The problem doesn't show in the non-interactive shell because the history function is not available there.

Many thanks to b0uncer and omnio, your suggestions have helped me greatly - problem solved (for my purposes, at least).

Thanks for that cfaj, I missed that snippet. I won't bother with a bug report.

I'm glad you solved it; I had my hard times with PPPOE which used to behave strangely. For example, I see that in your script you check only the pppoe-start output, but I also saw some cases when it said "connected" but there was no working internet connection and no traffic, so you will probably want to add a ping test or whatever, just to be sure. And sometimes it takes a while till the connection is actually working, so you should probably not execute the ping test immediately.

I don't know how exactly PPPOE works, but some ISPs provide a dynamic IP (via DHCP) *before* connecting with PPPOE, and if the client fails to receive that IP, PPPOE will fail too; in this case, just issuing "pppoe-stop; pppoe-start" would not suffice, the network interface needs to be reconfigured to get that dynamic IP first. This is a mess, if you ask me.

I hope there are always other ways than that. Let's say you wanted to give the script to your friends, mates etc. You would tell them to alter the pppoe-start script?

Omnio, you raise a good point on testing. I have only implemented testing the output of 'pppoe-start' because in the four years I have been using this ISP, I have not had one instance of a 'Connected!' message associated with a failed connection. The only failed connections have had 'TIMED OUT' in the logs. The communication medium is fibre-to-the-node, then Cat 5 cable to the house, which I've found to be very reliable. But you're quite right that if I were to pass the script onto my friends with, say, ADSL, then better testing would be called for.

Note that the 'pppoe-start' script is only establishing a connection to the equipment at the ISP. Ie, you get a line in to their system. If they have problems with other equipment that is needed to give you a connection to the Internet (DNS servers, routers, etc), then you will fail to get a line out to the Internet. Doing a 'pppoe-stop'/'pppoe-start' will not fix that problem. I have had a few occasions when the connection via 'pppoe-start' was successful, but had no service to email or the Internet. The symptoms are that you can ping the 'inet addr' and 'P-t-P' addresses (both listed against 'ppp0' from 'ifconfig'), but can't ping their DNS addresses, nor any other TCP/IP address in the Internet. You also can't ping a plain-language address (eg, www.google.com) as their DNS server is not working. That needed a phone call to the ISP to get them to fix their servers. As soon as you mention that you can ping the 'inet addr' and 'P-t-P', but not their DNS servers, they know the problem is at their end, or at the carrier's. On a couple of occasions, it has been the carrier's equipment, which includes the ethernet modem in my house (physically here, but owned by them). All that needed was a reboot of the modem - something to do with 'clearing the cache' at both ends of the connection with the carrier (a separate company to the ISP in my case).

You misunderstand me on this. I originally hacked the 'pppoe-start' script to take out the exclamation character to get my script to run (ie, I made it non-standard). When I say that I can now put the exclamation character back into the script, that is only to restore it to its original state, which is the same as what other users would have on their system.

I forgot to make mention of this. Unless your contract includes a static IP address, all ISP's will allocate you a dynamic IP address as part of the process of connecting with 'pppoe-start'. Since the ISP provides a dynamic IP address via DHCP, your network interface card should be configured to get an IP address from their DHCP server. In this case, reconfiguring the interface is not required. Whenever you attempt a connection (with a 'pppoe-start'), your network interface card is primed to receive an address via DHCP. This process is automatic and requires no reconfiguration on your part. In this case, the 'pppoe-start' command sent to your ISP is the equivalent of 'ifup' on your local network. If you are having problems connecting, maybe it's because there is not enough time between the 'pppoe-stop' and 'pppoe-start' commands. For example, my previous 'reconnection' script was a simple:This worked for a long time, and only recently began to result in 'TIMED OUT' errors. I then developed the new version that included error checking. With that, I increased the 'sleep' time to 10 seconds. I'm now thinking that I should increase that to 30 seconds or so, to give the ISP's servers enough time to fully log me out before I come back knocking on their door. If the server is delayed for any reason in logging me out, then it might refuse a connection, on the basis that I'm still 'logged in' as far as they're concerned.

[edit: minor change to expression]

Yep. To restart it, this is what I meant. It stays "configured" to get a dynamic IP, but I saw many cases when it fails to receive it and when a restart of the interface (and of the DHCP client apparently) is needed.
Wow, you're lucky.
Well, I was half joking.

I hope this wasn't already mentioned; I may have scanned the previous messages too quickly. The history expansion occurs in an interactive shell. If you have a shell running from a script, then a filename with an exclamation point in it shouldn't present the same problems. E.G. evaluating "$file" if the variable value contains an exclamation point won't cause surprises.

jschiwal said:
Yes, this was mentioned a few posts before:
I suppose I could have been a bit more explicit and said that scripts run in a non-interactive shell, and thus won't be subjected to history expansion, and therefore not be affected by the problem I was seeing. The mistake I made was to conduct testing directly in an interactive shell, assuming the effect would be the same as the non-interactive shell. Lots of bash tutorial sites recommend running commands in the shell to test that your code delivers what you want. Had I instead created a small script to replicate what I wanted (a trivial exercise in this case) instead of launching off at a tangent chasing false shadows, I would not have wasted a lot of time. That in itself has been an excellent lesson.

Yes, it probably would occur with a filename, but this thread has been about exclamation points in variables. For the sake of completeness and accuracy for Googlers, an exclamation point in a variable in a bash script will not present the same problem discussed here.

I had a typo, which I corrected. I changed should to shouldn't.

I had previously made the same discovery when including an exclamation point in an echo command where the string was in double quotes.

I just tried an interactive command where I had a variable with an exclamation point, so my memory was wrong on that point.

Since you can use single quotes or the backslash to escape it, then perhaps getting in the habit of doing so even if you are writing a script would be a good practice. Then your interactive testing would work.

echo Good Luck\!
salutation='Best Wishes'
echo "and $salutation"'!'

I hope it isn't too late to add to this thread. There is something else to watch for when testing code by entering lines in interactively.
If you change the IFS variable, as in
IFS='
'
Then you can run into a problem with some commands because the space character in the aliases doesn't separate the command from the arguments because space isn't in IFS. I usually back up IFS and restore it after the command I need it for.