Re: [XEmacs] Tramp Bug? -- Nachtrag

[Daniel Pittman]

On Mon, 23 Sep 2002, Kai Gro wrote:
> Mark Trettin <address@hidden> writes:
> 
>> Folgendes illustriert den Fehler:
>>
>> ,----
>> | beldin:/dev # ll null
>> | crw-rw-rw-    1 root     root       1,   3 Jun 17  2001 null
>> | beldin:/dev # echo blah | mimencode >/dev/null
>> | beldin:/dev # ll null
>> | crw-------    1 root     root       1,   3 Jun 17  2001 null
>> `----
> 
> Folks, I need your help.  As you know, Tramp tries to find out
> whether various inline coding commands work.  During this, it
> executes something like
> 
>     echo xyzzy | mimencode -b | mimencode -b -u >/dev/null
> 
> When this is done as root, the permissions of /dev/null change!  (See
> above.)
> 
> Isn't this really really strange?

It does seem that way. mimencode probably shouldn't be frobbing the
permissions at all, which seems likely. I really doubt the shell is
doing it. :/

> Do you have a suggestion what to do?  Hm.  Well maybe the best
> solution is not to redirect standard output and to hope that the
> output does not contain the string "tramp_exit_status" (that string
> is used to find the value of $? which tells us whether the command
> was successful).
> 
> Thoughts?

In my implementation of auto-detection, I piped the encoded data through
the remote decoder and looked for the correct data in the output stream.

OTOH I had a more unique marker for end-of-output, which probably made
me feel safer doing that...

> (I think programs shouldn't be allowed to frob permissions of files
> that output gets redirected to, especially not /dev/null.  Oh, well.)

It's a DWIM thing, and the primary reason that I don't like Perl and
friends. They try to do what I mean, except that I often didn't mean
that and want to cry when my system now fails. ;)

     Daniel

-- 
Absence extinguishes a small passion and increases a great one, 
as the wind extinguishes a candle and fans a fire.
        -- Francois duc de la Rochefoucauld