GNU bug report logs - #16045
24.3.50; rgrep can't work

Previous Next

Full log

Message #32 received at 16045 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: zijianyue <at> 163.com, 16045 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#16045: 24.3.50; rgrep can't work
Date: Thu, 05 Dec 2013 22:23:46 +0200

> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: monnier <at> iro.umontreal.ca,  zijianyue <at> 163.com,  16045 <at> debbugs.gnu.org
> Date: Thu, 05 Dec 2013 20:58:58 +0100
> 
> > Why should it parse it?  Isn't \n\ removed on the remote end before
> > the shell there interprets it?
> 
> I'm not sure, whether it works under any circumstance. For example:
> 
> $ cat <<EO\
> > F
> > xxx\
> > yyy
> > EO\
> > F
> > EOF
> xxxyyy
> EOF
> $ 
> 
> The heredoc does not understand the first EOF, when written as

Such commands have short lines anyway, so you would never need to
break them.  So in practice here documents should never be a problem.

Are there any other circumstances where a command cannot be broken in
an arbitrary place?

Anyway, you could break on whitespace, to be on the safe side.

> >> Where does it know from, how long a command line in the remote shell
> >> could be?
> >
> > How do you know that in grep.el?
> 
> grep.el doesn't know it either. But it knows more about the arguments,
> and where to add that line break.

The question was about the remote shell limitations, so knowing about
the arguments doesn't help.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.