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

Reply via email to