PATCH: Re: Superfluous CRs trouble completion routines in Cygwin

PATCH: Re: Superfluous CRs trouble completion routines in Cygwin

[Bart Schaefer]

[Redirected from -users to -workers]

On Oct 15,  6:02pm, Bart Schaefer wrote:
}
} I think the answer is that $_comp_setup in compinit should contain
} 
} 	local IFS=$'\r'"$IFS"

Upon further thought I believe it should instead set IFS to exactly
the expected string, rather than pulling in the IFS setting from the
surrounding environment.

Hence:


Index: Completion/compinit
===================================================================
diff -c -r1.9 compinit
--- Completion/compinit	24 Sep 2005 17:48:33 -0000	1.9
+++ Completion/compinit	16 Oct 2005 00:14:11 -0000
@@ -156,6 +156,7 @@
 # and don't get confused by user's ZERR trap handlers.
 
 _comp_setup='setopt localoptions localtraps ${_comp_options[@]};
+             local IFS=$'\'\ \\t\\r\\n\\0\''
              exec </dev/null;
              trap - ZERR'
 

Re: PATCH: Re: Superfluous CRs trouble completion routines in Cygwin

[Peter Stephenson]

Bart Schaefer wrote:
> On Oct 15,  6:02pm, Bart Schaefer wrote:
> }
> } I think the answer is that $_comp_setup in compinit should contain
> } 
> } 	local IFS=$'\r'"$IFS"
> 
> Upon further thought I believe it should instead set IFS to exactly
> the expected string, rather than pulling in the IFS setting from the
> surrounding environment.

Why don't we just try this and see if it breaks anything?  Carriage
returns are unusual enough in Unix that there's a good chance it
won't.

pws


This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com

Re: PATCH: Re: Superfluous CRs trouble completion routines in Cygwin

[Hannu Koivisto]

Bart Schaefer <schaefer@brasslantern.com> writes:

> [Redirected from -users to -workers]
>
> On Oct 15,  6:02pm, Bart Schaefer wrote:
> }
> } I think the answer is that $_comp_setup in compinit should contain
> } 
> } 	local IFS=$'\r'"$IFS"
>
> Upon further thought I believe it should instead set IFS to exactly
> the expected string, rather than pulling in the IFS setting from the
> surrounding environment.

I applied your patch to zsh 4.2.4 / Cygwin.  Now p4 <tab> causes a
segfault...  Seems to work (read: no change in p4 completion
behaviour) in zsh 4.2.5 / Linux.

-- 
Hannu

Re: PATCH: Re: Superfluous CRs trouble completion routines in Cygwin

[Bart Schaefer]

On Oct 20,  3:48pm, Hannu Koivisto wrote:
} Subject: Re: PATCH: Re: Superfluous CRs trouble completion routines in Cyg
}
} I applied your patch [adding \r to IFS] to zsh 4.2.4 / Cygwin.  Now p4
} <tab> causes a segfault...

Do other completions also segfault, or just that one?  Do you get any
output at all from complete-debug (ctrl-x question-mark)?  Does it
change anything if you remove the \\0 (NUL) from the IFS assignment?

(I'm pretty much shooting in the dark on that last one.)

Re: PATCH: Re: Superfluous CRs trouble completion routines in Cygwin

[Hannu Koivisto]

Bart Schaefer <schaefer@brasslantern.com> writes:

> On Oct 20,  3:48pm, Hannu Koivisto wrote:
> } Subject: Re: PATCH: Re: Superfluous CRs trouble completion routines in Cyg
> }
> } I applied your patch [adding \r to IFS] to zsh 4.2.4 / Cygwin.  Now p4
> } <tab> causes a segfault...
>
> Do other completions also segfault, or just that one?  Do you get any

Just that one (I tried ls, diff and cvs completions).

> output at all from complete-debug (ctrl-x question-mark)?  Does

No, it segfaults when I hit C-x ?

> change anything if you remove the \\0 (NUL) from the IFS assignment?

No.  However, when I removed \\r the problem went away.

-- 
Hannu

Re: PATCH: Re: Superfluous CRs trouble completion routines in Cygwin

[Bart Schaefer]

On Oct 21,  2:39pm, Hannu Koivisto wrote:
}
} Bart Schaefer <schaefer@brasslantern.com> writes:
} 
} > output at all from complete-debug (ctrl-x question-mark)?  Does
} 
} No, it segfaults when I hit C-x ?

Sorry, the interesting output in this case would have gone into a
file whose name begins with the value of $TMPPREFIX.  You won't see
anything on your terminal.  What I want to know is whether the file
contains anything.
 
} > change anything if you remove the \\0 (NUL) from the IFS assignment?
} 
} No.  However, when I removed \\r the problem went away.

That most likely means it's a problem with "read" (or something that uses
the variables assigned by "read").

Do you experience any problems with, for example,

    print "trailing spaces    " | read -A array

??  I just don't see any reason why $'\r' would be magical.

Re: PATCH: Re: Superfluous CRs trouble completion routines in Cygwin

[Peter Stephenson]

Bart Schaefer wrote:
> ??  I just don't see any reason why $'\r' would be magical.

It's a bit magical in Cygwin depending on whether you've told it to
translate ends of lines in the file system.  No idea if that's
relevant or not.

pws


This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com

Re: PATCH: Re: Superfluous CRs trouble completion routines in Cygwin

[Peter A. Castro]

On Fri, 21 Oct 2005, Peter Stephenson wrote:

> Bart Schaefer wrote:
>> ??  I just don't see any reason why $'\r' would be magical.
>
> It's a bit magical in Cygwin depending on whether you've told it to
> translate ends of lines in the file system.  No idea if that's
> relevant or not.

   For the Cygwin port, I'd updated Src/main.c to use a Cygwin specific
"feature" to force all read-only files opened by the shell to strip out
CRs.  This was necessary for reading shell scripts which might have been
created with dos carriage-control.
   Unfortinately, this only applies to read-only files (opened with
O_RDONLY), allowing for files opened for write to be influenced by the
filesystem settings.  Since the console stream is r/w, the above
"feature" doesn't apply.
   Since we are talking about console input, though, there may be a tty
setting to control weither CRs are passed to the input stream.  I'll see
if I can investigate this.

> pws

-- 
Peter A. Castro <doctor@fruitbat.org> or <Peter.Castro@oracle.com>
 	"Cats are just autistic Dogs" -- Dr. Tony Attwood

Re: PATCH: Re: Superfluous CRs trouble completion routines in Cygwin

[Bart Schaefer]

On Oct 23, 10:33am, Peter A. Castro wrote:
}
}    Since we are talking about console input, though, there may be a tty
} setting to control weither CRs are passed to the input stream.  I'll see
} if I can investigate this.

I'm not all that familiar with how Cygwin simulates UNIX pipelines.  We
are talking about command output piped to the "read" builtin -- is that
the same as console input?

In any case, stripping CRs from the i/o stream would only mask the
problem.  It'd be at least as helpful to know why adding a CR to the
IFS value causes a segmentation fault.

Re: PATCH: Re: Superfluous CRs trouble completion routines in Cygwin

[Peter A. Castro]

On Sun, 23 Oct 2005, Bart Schaefer wrote:

> On Oct 23, 10:33am, Peter A. Castro wrote:
> }
> }    Since we are talking about console input, though, there may be a tty
> } setting to control weither CRs are passed to the input stream.  I'll see
> } if I can investigate this.
>
> I'm not all that familiar with how Cygwin simulates UNIX pipelines.  We
> are talking about command output piped to the "read" builtin -- is that
> the same as console input?

Pipes in Cygwin are a, somewhat, strange beast, because the underlying
mechanism is Windows pipes (the working of which is a topic for a
different discussion).

Pipes can be effected depending on the CYGWIN env var.
If you set: CYGWIN=binmode
Then everything is sent through the pipe (this is the default).
If, however, you set: CYGWIN=nobinmode
Then CRLF will be translated to LF.
Unfortunately, this is a global and would effect every pipe opened
(though it can be overridden, but would mean special case shell code
everywhere).

> In any case, stripping CRs from the i/o stream would only mask the
> problem.  It'd be at least as helpful to know why adding a CR to the
> IFS value causes a segmentation fault.

Agreed.  I haven't been able to repo this scenario (yet).  If whoever can
repo it, could attach a debugger to the shell and the cause it to fault,
they should be able to catch where it's faulting (though finding the
correct thread might be a little tricky).

-- 
Peter A. Castro <doctor@fruitbat.org> or <Peter.Castro@oracle.com>
 	"Cats are just autistic Dogs" -- Dr. Tony Attwood