X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org From: Adam Dinwoodie To: "cygwin AT cygwin DOT com" Subject: Expanding @-pathnames from Cygwin bash Date: Wed, 13 Feb 2013 17:47:19 +0000 Deferred-Delivery: Wed, 13 Feb 2013 17:47:00 +0000 Message-ID: Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id r1DHm9Is004999 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