Hello,

A while ago I posted a small script I'd written to search for winning
lottery lines contained in a file. I simply called it 'lot'.

Many people helped me to do this, and although my finished version is
ludicrously basic, it works. Well, it did, and that is the 'thrust' of my
post here now.

Logged on locally to a Slackware 10 box, I can happily calculate, and
recalculate the (lack of) winning lines using 'lot' until, quite frankly, I
want to kill myself. No probs with that method. The fun starts when I try to
do exactly the same thing, but via an SSH client, like puTTY, connected into
*either* a Slackware 10 box, or a RH9 box.

If you haven't witnessed 'lot' yet, allow me to inflict it upon you (sorry) :

#!/bin/bash
date
echo -e "\nHere is the table of the syndicate numbers:\n"
cat -n /home/foo/lottery.txt
echo -e "\nWinning Numbers:\n"
cat /home/foo/winhope.txt
echo -e "\nMatching Lines:\n"
grep -nof /home/foo/winhope.txt /home/foo/lottery.txt


That's it.

When I try to run this via puTTY as explained above, the script can never
find the files 'winhope.txt' or 'lottery.txt', even though I know for sure
the paths are correct. It also can't find the 'date' command either. Hmm.

When I view the script in vim, only the 'echo' and 'grep' commands are
highlighted, 'date' and 'cat' are just plain text.

I don't understand what is going on with this. I haven't changed anything,
and have placed the files 'lot' relies on where they should be.

Is it the fact that I'm connecting via puTTY that's throwing a spanner in
the works ? The funny thing is (to me), is that on their own, the individual
commands in the script work fine. It's just not as convenient (and missing
the point a bit) as simply typing 'lot', like I used to, when logged
*locally* into a slackware 10 box.

Thanks for any info-nuggets anyone may have regarding this, and for your
time.

Cordially,

Kleeb.

Kleeb wrote:
> #!/bin/bash
> date
> echo -e "\nHere is the table of the syndicate numbers:\n"
> cat -n /home/foo/lottery.txt
> echo -e "\nWinning Numbers:\n"
> cat /home/foo/winhope.txt
> echo -e "\nMatching Lines:\n"
> grep -nof /home/foo/winhope.txt /home/foo/lottery.txt
>
>
> That's it.
>
> When I try to run this via puTTY as explained above, the script can never
> find the files 'winhope.txt' or 'lottery.txt', even though I know for sure
> the paths are correct. It also can't find the 'date' command either. Hmm.

in shell scripts it's often a good idea to use full paths to commands, so
type `/bin/date` rather than just `date'. (this doesn't go for echo and a
couple of other commands that are bash built-ins, though.)

i have no idea why your script doesn't find the files when you log in
through ssh, but it could be helpful if you posted the actuall errors you
get.

> When I view the script in vim, only the 'echo' and 'grep' commands are
> highlighted, 'date' and 'cat' are just plain text.

that's irrelevant. vim's font-lock determines which keywords get
highlighted and which don't.

--
Joost Kremers joostkremers@yahoo.com
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)

On 2004-08-23, Joost Kremers <joostkremers@yahoo.com> schrieb :
> in shell scripts it's often a good idea to use full paths to commands, so
> type `/bin/date` rather than just `date'. (this doesn't go for echo and a
> couple of other commands that are bash built-ins, though.)
>
> i have no idea why your script doesn't find the files when you log in
> through ssh, but it could be helpful if you posted the actuall errors you
> get.

Thanks for the reply Joost. Here is my modified version :

#!/bin/bash
/bin/date
echo -e "\nHere is the table of all the syndicate numbers ...\n"
/bin/cat -n /home/foo/lottery.txt
echo -e "\nWinning numbers :\n"
/bin/cat /home/foo/winhope.txt
echo -e "\nMatching lines :\n"
/bin/grep -nof /home/foo/winhope.txt /home/foo/lottery.txt

I'm starting the script with 'sh lot', as './lot' or just simply 'lot'
doesn't work at all, unlike when I was logged in locally to Slackware 10.
And I am in the same directory as the 'lot' script.

I get something about a 'bad interpreter' if I do anything other than 'sh
lot'.

Here is the output of the above, modified script :-

<begin output>

: No such file or directory

Here is the table of all the syndicate numbers ...

: No such file or directorytxt

Winning numbers :

: No such file or directorytxt

Matching lines :

: No such file or directory

<end output>

I know that Linux isn't really all that bothered about file extensions such
as '.txt', so I've tried with and without the extension, just as something
else to try. Same result, no such file.

It's got me stumped. All I had to do before was type 'lot', when I was
logged in locally to a slackware 10 box. Curiously, I get the same problems
I've mentioned when I ssh into a RH9 server I rent. Is it perhaps a setting
in puTTY I have to tweak ?

Thanks for your time anyway.

Cordially,

Kleeb.

Kleeb wrote:
> #!/bin/bash
> /bin/date
> echo -e "\nHere is the table of all the syndicate numbers ...\n"
> /bin/cat -n /home/foo/lottery.txt
> echo -e "\nWinning numbers :\n"
> /bin/cat /home/foo/winhope.txt
> echo -e "\nMatching lines :\n"
> /bin/grep -nof /home/foo/winhope.txt /home/foo/lottery.txt
>
> I'm starting the script with 'sh lot', as './lot' or just simply 'lot'
> doesn't work at all, unlike when I was logged in locally to Slackware 10.
> And I am in the same directory as the 'lot' script.
>
> I get something about a 'bad interpreter' if I do anything other than 'sh
> lot'.

that means that /bin/bash cannot be found. which kinda makes sense if
everything else cannot be found either.

> Here is the output of the above, modified script :-
>
> <begin output>
>
> : No such file or directory

normally, you'd get the filename before the colon. odd that it's missing
here...

> Here is the table of all the syndicate numbers ...
>
> : No such file or directorytxt

same thing, but now for some reason it prints txt at the end of the line.

> Winning numbers :
>
> : No such file or directorytxt

again

> Matching lines :
>
> : No such file or directory
>
> <end output>
>
> I know that Linux isn't really all that bothered about file extensions such
> as '.txt', so I've tried with and without the extension, just as something
> else to try. Same result, no such file.

well, linux *does* care about file extensions, in the sense that they are
part of the file name and cannot be excluded. so a file `myfile.txt' is
*always* different from a file `myfile'. therefore you cannot refer to the
former by typing the latter. (except if you are using a program that adds
file extensions, but bash certainly doesn't.)

> It's got me stumped. All I had to do before was type 'lot', when I was
> logged in locally to a slackware 10 box. Curiously, I get the same problems
> I've mentioned when I ssh into a RH9 server I rent. Is it perhaps a setting
> in puTTY I have to tweak ?

i'm stumped too... it might help to try ssh-ing from the slackware box to
the RH box and see if the same thing happens. if not, it is most likely a
putty problem. though i can't for the life of me figure out what it might
be...

--
Joost Kremers joostkremers@yahoo.com
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)

Kleeb wrote:

> I get something about a 'bad interpreter' if I do anything other than 'sh
> lot'.

This means that the #!/bin/bash line is incorrect. In your case, I would
venture a guess that there is some sort of trailing newline or whitespace
that isn't visible through puTTY, any possibly caused by it.

Jeffrey

Joost Kremers wrote:

> Kleeb wrote:
>> #!/bin/bash
>> date
>> echo -e "\nHere is the table of the syndicate numbers:\n"
>> cat -n /home/foo/lottery.txt
>> echo -e "\nWinning Numbers:\n"
>> cat /home/foo/winhope.txt
>> echo -e "\nMatching Lines:\n"
>> grep -nof /home/foo/winhope.txt /home/foo/lottery.txt
>>
>>
>> That's it.
>>
>> When I try to run this via puTTY as explained above, the script can never
>> find the files 'winhope.txt' or 'lottery.txt', even though I know for
>> sure the paths are correct. It also can't find the 'date' command either.
>> Hmm.
>
> in shell scripts it's often a good idea to use full paths to commands, so
> type `/bin/date` rather than just `date'. (this doesn't go for echo and a
> couple of other commands that are bash built-ins, though.)
>
> i have no idea why your script doesn't find the files when you log in
> through ssh, but it could be helpful if you posted the actuall errors you
> get.
>
>> When I view the script in vim, only the 'echo' and 'grep' commands are
>> highlighted, 'date' and 'cat' are just plain text.
>
> that's irrelevant. vim's font-lock determines which keywords get
> highlighted and which don't.


Does the target machine even have bash installed? If you can run it with
sh, then you could change that top line to
#!/bin/sh
and you won't have to type sh blahblah. Of course, it has to be executable.

Are your data files actually _on_ the target machine? You've ssh'd into
another computer - it can't see the files on your local computer, you
know. Maybe this is way too obvious, but that sure is what it sounds like.

Good Luck!
Rich

On 2004-08-23, Rich Grise <null@example.net> schrieb :

> Does the target machine even have bash installed? If you can run it with
> sh, then you could change that top line to
> #!/bin/sh
> and you won't have to type sh blahblah. Of course, it has to be executable.

Yes, the target machine does have bash installed. It's a 'full install' Slackware 10
box. I think I've tried your suggestion, and it yielded precisely the same results.
But I will try it again.

> Are your data files actually _on_ the target machine? You've ssh'd into
> another computer - it can't see the files on your local computer, you
> know. Maybe this is way too obvious, but that sure is what it sounds like.
>

Yes, the files 'lot' relies on are definitely on the machine. I always believe in
stating the obvious, especially when it comes to technology. I've no problem with
that. Start simple, then get more complicated if a problem warrants it.

What I'm going to do is rewrite the script again, on the machine. As another poster
in this thread suggested, it could be something in the script that's not visible to
me. I know this happens. I had a security 'plug-in' for a game server I owned, that
just would not run properly. Turned out it was a hidden space that gets inserted if
you copy from the HTML readme file supplied. Typing the lines out by hand solved the
problem.

Thanks to everybody for your time and suggestions.

Cordially,

Kleeb.

On 2004-08-23, Jeffrey Froman <Jeffrey@Fro.man> schrieb :
> Kleeb wrote:
>
>> I get something about a 'bad interpreter' if I do anything other than 'sh
>> lot'.
>
> This means that the #!/bin/bash line is incorrect. In your case, I would
> venture a guess that there is some sort of trailing newline or whitespace
> that isn't visible through puTTY, any possibly caused by it.
>

Take a bow sir, and a rather large cigar if you please.

I retyped the script out whilst ssh'd into my slackbox. 'lot' is now depressing
me again with no matching lines of any value.

I think some kind of copy and paste skullduggery was at work here. As you
suggested, there was more than likely some 'invisible' character/s lurking that
were crippling 'lot'. But no more.

Thanks again, and to all that replied.

Cordially,

Kleeb.

Kleeb wrote:
> I retyped the script out whilst ssh'd into my slackbox. 'lot' is now depressing
> me again with no matching lines of any value.
>
> I think some kind of copy and paste skullduggery was at work here. As you
> suggested, there was more than likely some 'invisible' character/s lurking that
> were crippling 'lot'. But no more.

the funny thing is, if this was really the case (and i agree that it
probably was) then it should not have made any difference whether you ran
the script while logged in locally or through ssh.

i have seen the problem you described before, and the cause was always some
invisible characters, usually \n\r where bash really needs \n only. but
because you mentioned the script worked fine when logged in locally, i
figured it must be something else here...

so i'm curious: did you create the script anew after logging in with putty,
c&p-ing it from the windows box? and after that, did you try running it
locally again? i'm betting the answers here are yes and no,
respectively. ;-)

--
Joost Kremers joostkremers@yahoo.com
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)

On 2004-08-23, Joost Kremers <joostkremers@yahoo.com> schrieb :
> c&p-ing it from the windows box? and after that, did you try running it
> locally again? i'm betting the answers here are yes and no,
> respectively. ;-)

Kind of .. I think what I actually did was something rather stupid as it
turns out. I wrote the script again in a Windows text editor (not notepad,
Crimson Editor) after hosing my dualboot XP/Slack box. I won't bore you with
the details of that experience.

I then installed Slackware 10 on my other box. Then I thought "Hello, I'll
just copy and paste the script into an open vim session on the slackbox.
Just so I'm sure that I can copy and paste properly using puTTY."

Of course, in went the script, and all seemed peachy. But as we all now
know, that wasn't the case at all.

Aside: I only have one monitor at present, so after I'd installed Slack on the
other machine, I powered down and gave my main computer it's monitor back. I
knew I'd be able to ssh in to slack and do everything I wanted to like that.
Which of course I can.

Typical that I didn't think of simply rewriting the *whole* script again
whilst ssh'd into slack. I was only changing bits of it, oblivious
to the fatal 'invisible' characters that were still present in the script.

Red faces aside, I'm pleased that 'lot' is now working again, and that
people were interested in helping me. Thanks again.

Cordially,

Kleeb.