[SOLVED] Do special vi chars lose meaning if copied and pasted in script?

Batistuta_g_2000 · 02-19-2013, 05:02 AM

So I have my mutt installer script, looks ok, could be way more intuitive but anyhow, I copied code from VMplayer ubuntu terminal onto windows box notepad and back across and the ^@ (Enter) value was lost when copied back over.

This is an assignment which (because the lecturer is a bit of a lazy-s.o.b) will only be marked if the script works - concerned that the special chars will disappear...any advice appreciated.

Code:

#/!/bin/bash
mkdir -p ~/assignment1/errors/
dpkg -s mutt 2>~/assignment1/errors/error 
# checks is mutt is there already
if [[ $? -eq 1 ]]
 then
    echo "To install mutt email application now press enter"
    echo "Or press any key followed by enter to exit to main menu"
    read entry1
   if [[ "$entry1" == "^@" ]]
    then
     echo "INSTALLING..........INSTALLING"
     echo "______________________________"
      sudo apt-get install mutt
   else
    echo "You need to install Mutt for program to work."
    echo "Exiting to main menu"
sleep 3s
fi
else
echo "installed already exiting in"
fi

exit 0

ntubski · 02-19-2013, 11:16 AM

^@ isn't an enter value, it's actually a nul (or 0) byte. Internally, bash uses nul bytes to represent end-of-string, so you can't have it as the value of a string. Therefore, "^@" is the same as "".

Also, your indentation is inconsistent, and you have an extra "/" in your "#!".

jpollard · 02-19-2013, 01:09 PM

Copy/paste is an operation done using the display buffer - therefore it will copy what is displayed, which is not necessarily the same thing as what was typed.

suicidaleggroll · 02-19-2013, 01:20 PM

Why are you copy-pasting it into Notepad? Just scp/ftp/email it or stick it on a USB drive. Copy/paste can lose a lot of info like jpollard said. Tabs turn into spaces, special characters turn into their displayed equivalents, etc.

Batistuta_g_2000 · 02-19-2013, 01:32 PM

Quote:

Originally Posted by ntubski

^@ isn't an enter value, it's actually a nul (or 0) byte. Internally, bash uses nul bytes to represent end-of-string, so you can't have it as the value of a string. Therefore, "^@" is the same as "".

Also, your indentation is inconsistent, and you have an extra "/" in your "#!".

Thanks, not too worried about the indententation in script (but should have put in properly to forum), thanks for the shebang error spotted. I have my keyboard config set to UK and when I control-v and hit Enter is comes out ^@ but if I do control-v and leave a second and press enter I get ^M. I tested the ENTER with the following script and result below, does it look ok?

Thanks

Code:

#!/bin/bash
echo "enter command enter"
read entry
if [ $entry == ^@ ] ; then
echo "ENTER"
else
echo "Not ENTER_______"
fi

Output

UBUNTU::./tester
enter command enter

ENTER

Could it be wrong?

theNbomr · 02-19-2013, 07:14 PM

Any time you start thinking 'special characters' in a shell script, you should be concerned. There aren't really any special characters required in a shell script, and anything that looks like one is more likely to give you grief than joy. When editing a script to run on a Linux host, edit the script on the Linux host. There are special characters in DOS/Windows editors called Carriage Returns which will give you grief.
And, since you're learning about Linux, you should embrace it in its full glory; use it, learn it, love it.

ntubski · 02-20-2013, 12:36 AM

Quote:

Originally Posted by Batistuta_g_2000

I have my keyboard config set to UK and when I control-v and hit Enter is comes out ^@ but if I do control-v and leave a second and press enter I get ^M. I tested the ENTER with the following script and result below, does it look ok?

It really doesn't matter what happens with control-v Enter (although that behaviour sounds a bit strange), the read command reads a line of input, ie it gets the text up until the a newline is input. If the user presses Enter straight away, then there is no text, so just use

Code:

if [ "$entry" == "" ] ; then
   echo "ENTER"
fi
## or
if [ -z "$entry" ] ; then
   echo "ENTER"
fi

To reiterate, bash can't see the ^@ character in strings:

Code:

~/tmp$ x="foo"
~/tmp$ echo ${#x}
3
~/tmp$ x=""
~/tmp$ echo ${#x}
0
~/tmp$ x="^@"
~/tmp$ echo ${#x}
0
~/tmp$ x="^@^@^@"
~/tmp$ echo ${#x}
0

jschiwal · 02-20-2013, 12:45 AM

There is a utility called dos2unix that will convert DOS nl/return characters to the unix NL character. Scripts entered in notepad won't run until you fix the line endings. You will have the same problems with make files and name=value entries in config files.

You can also use the "od" command to examine control characters in text files. You can also use sed or vim to replace the end characters as well.

Batistuta_g_2000 · 02-20-2013, 05:49 AM

Quote:

Originally Posted by theNbomr

Any time you start thinking 'special characters' in a shell script, you should be concerned. There aren't really any special characters required in a shell script, and anything that looks like one is more likely to give you grief than joy. When editing a script to run on a Linux host, edit the script on the Linux host. There are special characters in DOS/Windows editors called Carriage Returns which will give you grief.
And, since you're learning about Linux, you should embrace it in its full glory; use it, learn it, love it.

Good advice, thanks.

---------- Post added 02-20-13 at 11:49 AM ----------

Quote:

Originally Posted by ntubski

It really doesn't matter what happens with control-v Enter (although that behaviour sounds a bit strange), the read command reads a line of input, ie it gets the text up until the a newline is input. If the user presses Enter straight away, then there is no text, so just use

Code:

if [ "$entry" == "" ] ; then
   echo "ENTER"
fi
## or
if [ -z "$entry" ] ; then
   echo "ENTER"
fi

To reiterate, bash can't see the ^@ character in strings:

Code:

~/tmp$ x="foo"
~/tmp$ echo ${#x}
3
~/tmp$ x=""
~/tmp$ echo ${#x}
0
~/tmp$ x="^@"
~/tmp$ echo ${#x}
0
~/tmp$ x="^@^@^@"
~/tmp$ echo ${#x}
0

Got it, thanks a lot for the help.