Shell Programming and Scripting

I am using : << cut / cut to comment out block of code.
Works fine on few lines of script, then it gives me this cryptic error when I try to comment out about 80 lines.

The "warning " is at last line of script.

Code:

 done < results
 169  echo "END read all positioning parameters" 
 170 pause
 171 }
 172
 173 :<<cut         ERROR HERE  
 174 #do
 175 #if [ "$(( $choice % 2))" -ne 0 ]; 
 176 # echo $choice
 177 #done 
 178  pause 
 179 while read choice

Code:

   	 	 	 	   pi@pi:/usr/bin $ sudo Z-5.sh
 + debug=true
 /usr/bin/Z-5.sh: line 3540: warning: here-document at line 173 delimited by end-of-file (wanted `cut')
 + :
 /usr/bin/Z-5.sh: line 173: % 2: syntax error: operand expected (error token is "% 2")
 pi@pi:/usr/bin $

There is a utility called cut and I would not use this as the delimiter of a here document.
Does the closing line of the here document hold only the word cut, without any whitespaces or other characters?

Yes, here is my working code

Code:

 calc_wt_size
 140 : <<cut
 141 x=1
 142 while [ $x -le 5 ]
 143 do
 144   echo "Welcome {${x}} times"
 145   x=$(( $x + 1 ))
 146 done
 147 pause  
 148 cut          on separate line 
 149 # TOK echo "AFTER CUT "

When I use cut in same file again it gives me error .
One was as originally posted

Here is the new error I am getting

Code:

+ echo 'ANOTHER  cut '
ANOTHER  cut 
+ pause
+ read -p 'Press [Enter] key to continue...' fackEnterKey
Press [Enter] key to continue...
+ :
/usr/bin/raspi-config-DEBUG.sh: line 209: % 2: syntax error: operand expected (error token is "% 2")
/usr/bin/raspi-config-DEBUG.sh: line 3522: syntax error near unexpected token `}'
/usr/bin/raspi-config-DEBUG.sh: line 3522: `}'

And here is the code causing the new error

Both lines 209 and 210 cause same error when uses separately.

Code:

echo "ANOTHER  cut "
 208 pause 
 209  : <<cut
 210 : <<cut
 211 echo "AFTER LAST cut @line $LINENO"
 212 pause 
 213 do
 214 #if [ "$(( $choice % 2))" -ne 0 ];
 215 #echo $choice
 216 #pause 
 217         case $choice in

This is truly bizarre.
Did you take notice of cero's reply!
I will re-iterate his reply:
"""There is a utility called cut and I would not use this as the delimiter of a here document."""

Reading your OP implies you want to cut lines out of an executable script on the fly.
Am I correct?
If YES, then I would seriously reconsider what you are doing.
There may be other languages but IIRC the only one I know of that can delete lines on the fly is the Sinclair QL's SuperBASIC.
I am sure bash would get shell shock trying to do this. <pun intended>

PHP users routinely remove and replace executable PHP code “on the fly”.

This is pretty standard these days to dynamically change executable code in runtime.

I have been struggling with bash for less than a month now.

The idea was to use existing bash script and ADD some functionality to it.

When I do coding I like to keep my attempts in code so I do not repeat it.

So I am spoiled by C ability to comment out block of code and found that using "cut" can be used in bash. Unfortunately I have learn the "#" used at the bash scrip in this fashion #!... is really not "commented out line " - so this "problem using "cut" may be same issue.

BTW I did build a simple test function and using two "cut' in succession works just fine - that is not the issue.

I have been writing "code" for few years and firmly believe the "computer" will skip commented out code as instructed and it really does not bother me I my code contains code which is NOT executed one way or another.



Right now my code just "exit"s before getting to offending code.
I will try to analyze / delete the offending code to get rid of this error.

No, it is "really commented out". The whole story is this:

In OSes like DOS what is executable is determined by file extension: "something.EXE" is executable, "something.BLA" is not. In UNIX this is not the case. What is executable is determined by a filesystem flag, the "executable" flag:

Code:

# ls -l
total 180
-rwxrwxr-x 1 bakunin users  9224 Feb 15  2018 executable
-rw-rw-r-- 1 bakunin users  9224 Feb 15  2018 nonexecutable

Now this works fine for a all directly executable code like compiled source. But to run a script the mechanism is: load the interpreter, then load the script, feed it to the interpeter as input and only then let the interpreter run!

The problem is in the first step: UNIX has an abundance of interpreters: some dozen of shells, Python, Ruby, PERL, awk, ... . The list is endless. The question is: which interpreter to load?

For this there is the "magic" mechanism: when you try the file-command you will see something like this:

Code:

# file myfile
myfile: ASCII text

# file myscript
myscipt: Korn shell script, ASCII text executable

The file-command relies on a file /etc/magic in which rules for guessing the file type are laid out: something like "if the first three bytes resemble 'XYZ' then the file type is ...".

This worked fine in the beginning of UNIX - when there were two or three interpreters and they all had rather different syntax. Alas, we have different shells (Korn shell, bash) derived from other shells (Bourne shell) so that their syntax is 99% identical and such a rule set is bound to fail more often then not.

Therefore an invention was made: because everything after an octothorpe ("#" - and, yes, that is the correct name for that thing) is a comment in shell languages a "special comment" was introduced: if the FIRST line is a comment, further qualified by an exclamation mark AND if there is no whitespace before then everything following the exclamation mark is interpreted as the pathname of an interpreter which is loaded and then fed the script. This is how the system knows that for these files:

Code:

#! /bin/bash
echo hello world!

Code:

#! /my/interpreter
FOO-bar hello world!

it has to load /bin/bash in the first case but /my/interpreter in the second (to which the command "FOO-bar" hopefully makes sense). Notice that this only affects the OS kernel, which has to pick the correct interpreter! For the script itself this first line is just an ordinary comment.

I hope this helps.

bakunin