The UG states
> Cygwin programs expand their arguments starting with "@" in a special way. If
> a file pathname exists, the argument @pathname expands recursively to the
> content of pathname.
-- http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-at
It then contrasts "the behaviors of the bash built-in echo and of the program
/bin/echo." The implication I read is that the bash built-in echo doesn't
expand @-arguments because it's a built-in, not a fully-fledged program.
However, this doesn't seem to be what's happening. Running on my Cygwin system:
$ echo 'Hi' >testfile
$ echo 'Hi testfile' >args
$ type grep
grep is hashed (/usr/bin/grep)
$ grep @args #This hangs until I hit ^C, waiting for input
$ echo '@args' | grep @args #This shows grep looks for the literal
string "@args"
@args
$ cmd
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\>c:\cygwin\bin\grep @args
c:\cygwin\bin\grep @args
Hi
By my reading of the UG, since grep is a Cygwin program, it should always
expand "@args" to the contents of the "args" file. However this doesn't seem
to happen when grep is run from within bash, only within the Windows shell.
I think this is an error in the UG: my first guess is this behaviour is only
invoked when the parent process isn't a Cygwin process. If so, the UG
shouldn't explain the behaviour in the example as being due to echo being a
bash built-in; that behaviour also occurs if you invoke echo.exe.
--
Adam Dinwoodie
Messages posted to this list are made in a personal capacity.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
