On 17 Dec, Angus Lees wrote:
> On Wed, Dec 15, 1999 at 09:57:40PM +1100, [EMAIL PROTECTED] wrote:
> > Here's a strange thing; I have a couple of scripts; for flushing mail in
> > and out when my wife or I am dialled up. The fecthmail command in the
> > script fails, but the same command run from the command line works!
[...]
> > open("/etc/passwd", O_RDONLY) = 3
> > read(3, "root:<censored again>:0:0:root:/roo"..., 4096) = 658
> > close(3) = 0
>
[...]
> it is normal that a read returns the last bytes, then the next read
> returns 0 - i can only assume that the second case found what it was
> looking for (a particular login name) and thus closed /etc/passwd
> without needing to reach EOF. why the first case doesn't find this
> login name i don't know..
Exactly. The fact that the first read was short means it had reached
eof anyway. The first case does find the login name. So should the
2nd, but it's the one that keeps reading and fails.
> you could try putting the details in a .fetchmailrc, particularly
> since you can put the password there too and avoid the prompting
> altogether. i've always done it this way and never had any troubles.
I'm uncomfortable having a password stored in the clear in a user's
file. I feel more comfortable having the passwords stored in a root
owned read-only file.
>
> without seeing the script or the full straces, i'm guessing something
> like:
>
> - you have more than one version of fetchmail installed and PATH is
> different
Ah, interesting idea. That could be it.
> - fetchmail doesn't prompt for a password (or somehow behaves
> differently) if stdin isn't a tty (and you are somehow redirecting
> stdin away)
That's what I thought, initially. There is no re-direction of stdin,
though.
> - some other env change (though i don't see what)
Me either.
> re: the difference between "#!/bin/sh" and "#!/bin/bash"
>
> 1. /bin/sh mightn't be bash - it could be something like ash instead
> (ash is much smaller/simpler, and so runs sh scripts faster)
That, I knew.
> 2. bash (supposedly) behaves slightly more POSIXLY_CORRECT when
> invoked as "sh"
That, I didn't know. Thanks!
Thanks for the other suggestions, I'll keep prodding at it.
luke
--
SLUG - Sydney Linux Users Group Mailing List - http://www.slug.org.au
To unsubscribe send email to [EMAIL PROTECTED] with
unsubscribe in the text