Hey there. I am trying to create a program that uses bcrypt to massively encrypt an entire directory of files. bcrypt however requires two inputs: an 8+ character encryption key and a retype of the key before it encrypts a file. So i'm trying to use the "here operation" to input the two keys. However, I get the error

line 16 (#the end of the file): syntax error: unexpected end of file

Here is the code:



#!/bin/bash
echo Welcome. Process A: Encryption:
echo Directory:

repository="/home/ben/Desktop/virus" # read directory to be encrypted
for files in `ls $repository` # get list of files
do
echo "Encrypting...........$files"
bcrypt /home/ben/Desktop/virus/25.asm << THE_END
11221122
11221122
THE_END
done



It seems to me that this code should work. Is there some problem with using the here operation inside a for-in loop? Thanks for any help

Ben

Did you try :

cat << THE_END | bcrypt /home/ben/Desktop/virus/25.asm
11221122
11221122
THE_END

Isn't there an extra space between << and THE_END? That could be your problem. I don't think whitespace is ignored between << and the end-word.

Hello.

cat << THE_END | bcrypt "$repository/$files

did not work, returning the same error message:
line 16 (#the end of the file): syntax error: unexpected end of file


Removing the whitespace also did nothing to change it. Its weird because when I use the "here operation" by itself (without the for loop) it works fine but once the bash interpreter reads "<<" it pulls that error message. Whats going on? Here's what i have now.

#!/bin/bash
echo Welcome. Process A: Encryption:

repository="/home/ben/Desktop/virus" # read directory to be encrypted
for files in `ls $repository` # get list of files
do
echo "Encrypting...........$files"
bcrypt "$repository/$files"<<THE_END
11221122
11221122
THE_END
done

You probably have a CR-LF after one of the "THE_END" string, while the other has only LF (which is the correct line terminator under Unix).

how do i correct the line feed problem?
--ben

1: make sure it is the problem (cat -v yourscript.bash will tell you)
2: remove the CRs with an editor (I use /bin/vi on solaris that shows the CRs, vim -C should work too)

Might be an extra space or tab character at the end of the THE_END. With vi you can use

:set list

to have it replace print non-printable characters (for example, ^I is printed out where ever there is a tab). $ is used for end-of-line so you should see

THE_END$

and not

THE_END $


When done,

:set nolist

sets the output back to the default view.

There is nothing about the for loop that is keeping the here doc from working, but you're never seeing the string THE_END all on a line by itself, and as a result done is seen as part of the input to the bcrypt command and not the end of the loop. If you were typing on the command-line, then you'd just keep getting the > prompt. But the script ends, and you get this error.

BTW, you can do

for $directory/*
do
...
done

instead of

for `ls $directory`
do
...
done

yeah, i figured the here operation was reading beyond the delimiter. Thats kindof cool that you can see the feeds and carriages in VI. I tried it but i still found no unneccesary ^I or ^Ts or $ with whitespace. However, what i did was take the here operation, make it its own separate script that took a command line argument, and made my main program call it. Thanks for all your help.

The syntax is correct and it's work with ksh (Korn Shell).

Bash have problems with here document since a long time!

http://lists.gnu.org/archive/html/bu.../msg00050.html


Make this test

for ((i=1;i<10;i++))
do
cat <<THE_END
$i
THE_END
done

If I were writing this, I would get the input to send into a variable once in the beginning of the program, then echo that variable as needed. That means (1) The interpreter doesn't need to search for THE_END each time, (2) you can more easily change where you get the response string from in the future (you may want to store it in a file or something, and (3) you have the option of verifying it contains exactly what you want before you use it.

BTW, can you just do
MY_RESPONSE="11221122
11221122
"

This should answer issues on bash/ksh, leading spaces etc.

[CODE]
SF1B:/supmis/soumen/tmp> ls -l $(which bash)
-r-xr-xr-x 1 root bin 578964 Mar 2 2002 /usr/bin/bash
SF1B:/supmis/soumen/tmp> ls -l $(which ksh) $(which bash)
-r-xr-xr-x 1 root bin 578964 Mar 2 2002 /usr/bin/bash
-r-xr-xr-x 3 root bin 201052 Aug 5 00:17 /usr/bin/ksh
SF1B:/supmis/soumen/tmp> cat ttm
echo "Filename : $1"
read a
read b
echo "First param : $a"
echo "Second param : $a"
SF1B:/supmis/soumen/tmp> cat ttn
fdir=/tmp
par1=1234
par2=5678

for i in $(ls $fdir/*.dat) ; do
ttm $i <<THE_END
$par1
$par2
THE_END
done
SF1B:/supmis/soumen/tmp> bash ttn
Filename : /tmp/UTH2006.dat
First param : 1234
Second param : 1234
Filename : /tmp/bradvc.dat
First param : 1234
Second param : 1234
SF1B:/supmis/soumen/tmp> ksh ttn
Filename : /tmp/UTH2006.dat
First param : 1234
Second param : 1234
Filename : /tmp/bradvc.dat
First param : 1234
Second param : 1234
SF1B:/supmis/soumen/tmp>
[/CODE}

This is on a solaris machine. But that should'nt be a problem, right?

HTH.

Sorry about the formatting tag error. Here is a repost:

The following will encrypt/decrypt an extremely large number of files in the directory $mydir.
It asks for the password just once for decryption or twice for encryption.
It is recursive i.e. it operates on all the subdirectories of $mydir too.
It does not work with filenames which contain spaces.
Such files are ignored, but without stopping the rest being processed.
Unusual filename characters might also cause problems.
Hidden files (e.g. .directory) are excluded by the option -name '[!.]*'
I've found that bcrypt on its own can cope with well over 2000 files at once; xargs greatly extends this by its ability to break up a much larger number of files into manageable chunks:-
The yes command can be used to pipe the password in as many times as bcrypt needs it, in this case once or twice:-
If this was running in a terminal the "Encryption key:" prompt would be displayed but there is no need to type anything as the password (held in the variable $pw) will be entered silently by the yes command.
This makes it easier to use a long password but is less secure and so should be used with caution.
e.g. the password might leak to the swap space by memory paging, or if $pw was set by typing into a terminal it could be recorded in the terminal history file.