GNU bug report logs - #23227
Inconsistent behavior for --file=~/some-file

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 23227 in the body.
You can then email your comments to 23227 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Santiago Ruano Rincón <santiagorr <at> riseup.net>
To: bug-grep <bug-grep <at> gnu.org>
Subject: Inconsistent behavior for --file=~/some-file
Date: Tue, 5 Apr 2016 23:55:41 +0200

Hi,

grep fails to parse the tilde (~) to represent $HOME, when it is used to
give a file's path to --file=, but it works with --file

% echo "a" > ~/tmp-pattern
% echo "hola" | LANG=C grep --file=/home/santiago/tmp-pattern
hola
% echo "hola" | LANG=C grep --file /home/santiago/tmp-pattern
hola
% echo "hola" | LANG=C grep --file ~/tmp-pattern
hola
% echo "hola" | LANG=C grep --file=${HOME}/tmp-pattern 
hola
% echo "hola" | LANG=C grep --file=~/tmp-pattern
grep: ~/tmp-pattern: No such file or directory

This was filed in debian:
https://bugs.debian.org/504804

Cheers,

Santiago

Message #12 received at 23227-done <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Santiago Ruano Rincón <santiagorr <at> riseup.net>,
 23227-done <at> debbugs.gnu.org,
 "contr >> GNU bug control" <control <at> debbugs.gnu.org>
Subject: Re: bug#23227: Inconsistent behavior for --file=~/some-file
Date: Tue, 5 Apr 2016 16:03:48 -0600

[Message part 1 (text/plain, inline)]

tag 23227 notabug
thanks

On 04/05/2016 03:55 PM, Santiago Ruano Rincón wrote:
> Hi,
> 
> grep fails to parse the tilde (~) to represent $HOME, when it is used to
> give a file's path to --file=, but it works with --file

That's not grep's fault, but the shell's.


> % echo "hola" | LANG=C grep --file ~/tmp-pattern
> hola
> % echo "hola" | LANG=C grep --file=${HOME}/tmp-pattern 
> hola

Try this to see that it is the shell:

$ echo testing --file ~/tmp-pattern
testing --file /home/eblake/tmp-pattern
$ echo testing --file=~/tmp-pattern
testing --file=~/tmp-pattern
$ echo testing --file=$HOME/tmp-pattern
testing --file=/home/eblake/tmp-pattern

Tilde expansion in the shell is defined by POSIX to only happen if ~
occurs as the first character of a word (or, in special cases such as
"export foo=~/bar" where a shell builtin is consuming its operands in
assignment context - but this is not one of those special cases).  IN
other words, for ALL other uses where you are passing '--option=value',
tilde expansion does NOT happen in 'value'; and you are correct that
using '--option value' as two separate arguments (for all long options
where the argument is not optional) is the easiest way to get ~ to the
front of the word and thus have tilde expansion again.

Since this behavior is baked into your shell, there's nothing grep can
do about it, so I'm closing this as not a bug.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

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

From: Eric Blake <eblake <at> redhat.com>
To: 23227 <at> debbugs.gnu.org, santiagorr <at> riseup.net
Subject: Re: bug#23227: Inconsistent behavior for --file=~/some-file
Date: Tue, 5 Apr 2016 16:14:03 -0600

[Message part 1 (text/plain, inline)]

On 04/05/2016 04:03 PM, Eric Blake wrote:
> Tilde expansion in the shell is defined by POSIX to only happen if ~
> occurs as the first character of a word

> 
> Since this behavior is baked into your shell, there's nothing grep can
> do about it, so I'm closing this as not a bug.

And before you argue that "surely grep could be taught to treat
"--file=~/..." as a request to perform tilde expansion itself, since the
shell didn't", you'd have to patch the same problem in EVERY OTHER
program that has long options, AND you'd have an ambiguity for:

--file '~/...' # I want a literal tilde, not shell tilde expansion

That is, grep doing tilde expansion in addition to the shell could cause
places where you get improper expansion in spite of intentionally using
shell quoting to avoid tilde expansion.  Besides, tilde expansion in
general is NOT trivial to reimplement (while ~ vs. $HOME is easy,
~username is not - don't believe me? Look at how many lines of code bash
uses to implement it), and it's not worth bloating every other
application to redo expansion when we can already require the shell to
do it for us.  You just have to learn to use the shell correctly so that
expansion happens where you want it.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

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

From: Santiago Ruano Rincón <santiagorr <at> riseup.net>
To: Eric Blake <eblake <at> redhat.com>, 504804-done <at> bugs.debian.org
Cc: 23227 <at> debbugs.gnu.org
Subject: Re: bug#23227: Inconsistent behavior for --file=~/some-file
Date: Wed, 6 Apr 2016 10:10:35 +0200

El 05/04/16 a las 16:14, Eric Blake escribió:
> On 04/05/2016 04:03 PM, Eric Blake wrote:
> > Tilde expansion in the shell is defined by POSIX to only happen if ~
> > occurs as the first character of a word
> 
> > 
> > Since this behavior is baked into your shell, there's nothing grep can
> > do about it, so I'm closing this as not a bug.
> 
> And before you argue that "surely grep could be taught to treat
> "--file=~/..." as a request to perform tilde expansion itself, since the
> shell didn't", you'd have to patch the same problem in EVERY OTHER
> program that has long options, AND you'd have an ambiguity for:
> 
> --file '~/...' # I want a literal tilde, not shell tilde expansion
> 
> That is, grep doing tilde expansion in addition to the shell could cause
> places where you get improper expansion in spite of intentionally using
> shell quoting to avoid tilde expansion.  Besides, tilde expansion in
> general is NOT trivial to reimplement (while ~ vs. $HOME is easy,
> ~username is not - don't believe me? Look at how many lines of code bash
> uses to implement it), and it's not worth bloating every other
> application to redo expansion when we can already require the shell to
> do it for us.  You just have to learn to use the shell correctly so that
> expansion happens where you want it.
> 

Ok, you're right! Thanks for your answer, and I'm closing this bug in
Debian.

Cheers,

Santiago

Previous Next

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