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!
[from script]
> open("/etc/passwd", O_RDONLY) = 3
> read(3, "root:<censored>:0:0:root:/roo"..., 4096) = 658
> read(3, "", 4096) = 0 ** <--- The extra read() **
> close(3) = 0
[at shell]
> open("/etc/passwd", O_RDONLY) = 3
> read(3, "root:<censored again>:0:0:root:/roo"..., 4096) = 658
> close(3) = 0
from read(2):
RETURN VALUE
On success, the number of bytes read is returned (zero
indicates end of file) ...
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..
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.
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
- fetchmail doesn't prompt for a password (or somehow behaves
differently) if stdin isn't a tty (and you are somehow redirecting
stdin away)
- some other env change (though i don't see what)
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)
2. bash (supposedly) behaves slightly more POSIXLY_CORRECT when
invoked as "sh"
--
- Gus
--
SLUG - Sydney Linux Users Group Mailing List - http://www.slug.org.au
To unsubscribe send email to [EMAIL PROTECTED] with
unsubscribe in the text
