X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:to:date:subject:message-id:references
	:in-reply-to:content-type:content-transfer-encoding
	:mime-version; q=dns; s=default; b=d9gjEJSFXhe0nCcZ22RGFVUj++auF
	HgwvpWMdAL0QwQXWJb8Ba39mdDGSSyuYH85qI6tx1LJKK2u+itUCRF9xs/HRmXKb
	ffk/AK64rM19DuX09v5G6a/yaAt6NHwFiVq+lZsnOebGO1g6diKCny566bnEPY6F
	WiKbEOrEHQeX1Q=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:to:date:subject:message-id:references
	:in-reply-to:content-type:content-transfer-encoding
	:mime-version; s=default; bh=ydlYe/I+z6wPkIazF0SOdYfslP0=; b=oud
	VUzey82Q9aEaR+5oEW1Vi+B9YWl9cqiE9L+Ms0wlxgjV+NQVw8kGfgYPhyjZ6Tz6
	pnRqwspS5YltWoqUhj6FV8Ev4rS6nUfJ7nDpFeaMUGVgMUWQDESgm8AB8WIsSIAy
	J+muvnm9dY08ZxahHhLPI6AleF75Fw/gGqIhqf70=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: Yes, score=5.2 required=5.0 tests=AWL,BAYES_50,SPAM_URI1,SPF_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2
X-HELO: ecl1mtaoutpex02.symantec.com
From: Bob McGowan <Bob_McGowan AT symantec DOT com>
To: "cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
Date: Wed, 7 Jan 2015 10:34:30 -0800
Subject: Re: Force "ls" to show .exe extension
Message-ID: <D0D2B422.8725%bob_mcgowan@symantec.com>
References: <loom DOT 20150106T203355-631 AT post DOT gmane DOT org> <1941710256 DOT 20150107013212 AT yandex DOT ru> <loom DOT 20150107T010713-891 AT post DOT gmane DOT org> <6CF2FC1279D0844C9357664DC5A08BA20FA979B4 AT msgb09 DOT nih DOT gov> <loom DOT 20150107T164855-744 AT post DOT gmane DOT org>
In-Reply-To: <loom.20150107T164855-744@post.gmane.org>
user-agent: Microsoft-MacOutlook/14.4.4.140807
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
X-IsSubscribed: yes
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id t07IYrOr018519

On 1/7/15, 8:07 AM, "Paul" <Paul DOT Domaskis AT gmail DOT com> wrote:

>Buchbinder, Barry (NIH/NIAID) [E] <BBuchbinder <at> niaid.nih.gov> writes:
>>Paul sent the following at Tuesday, January 06, 2015 7:12 PM
>>> I'm wading through many files in two file trees. In particular, I'm
>>> looking at corresponding directories in the two trees where "diff
>>> -qr" revealed differences. I want the absolute truth of what the
>>> filename is with minimal distractions about how to achieve that.
>>> Then, I can focus on figuring how those files came about, and how
>>> the differences arose.
>> 
>> Not a Cygwin solution but the following should give real names.
>> 
>> cmd /c dir /b /a:
>> 
>> (The /a: makes sure that hidden files are listed.)
>
>That works great, Barry.  The following also works:
>
>   cmd /c dir /b /a: | dos2unix | xargs ls -ltd
>
>However, variation#1
>
>   type -pa pdfcrop | xargs cmd /c dir /b /a:
>
>doesn't work because dir expects DOS filenames (I suspect).
>
>Variation#2
>
>   type -pa pdfcrop | xargs cygpath -aw | xargs cmd /c dir /b /a:
>
>doesn't work because the backward slashes are interpretted by Escapes
>by bash.
>
>Variation#3 (on *one* line):
>
>   type -pa pdfcrop | xargs cygpath -aw -t mixed | xargs cmd /c dir /b
>   /a:
>
>doesn't work because
>
>   Parameter format not correct - "cygwin64"
>
>To find out what was going on, I stuck an "echo" in front of cmd,
>which yielded the following (on *one* line):
>
>   cmd /c dir /b /a: C:/cygwin64/home/User.Name/bin/pdfcrop
>   C:/cygwin64/usr/share/texmf-dist/scripts/pdfcrop/pdfcrop.pl
>   C:/cygwin64/usr/share/texmf-dist/scripts/pdfcrop/pdfcrop.pl
>
>I think the dir command is interpreting /cygwin64 as a command switch.

That is true.

To further add to the confusion this can cause (and a possible solution
after this):

$ ls -l
total 3
-rwxr-xr-x 1 rmcgowan None 45 Jan  6 15:12 abc.bat
-rwxr-xr-x 1 rmcgowan None 50 Jan  7 09:48 abc.exe # note this file size
-rwxr-xr-x 1 rmcgowan None 48 Jan  6 15:15 abc.sh
$ date > abc # NOTE file name...
$ l
total 3
-rwxr-xr-x 1 rmcgowan None 45 Jan  6 15:12 abc.bat
-rwxr-xr-x 1 rmcgowan None 30 Jan  7 09:48 abc.exe # And here.
-rwxr-xr-x 1 rmcgowan None 48 Jan  6 15:15 abc.sh


And trying to do a 'touch abc' changes the date associated with abc.exe
(it was Jan 6, is now Jan 7).

But 'mkdir abc' creates the directory abc.

And in an empty directory, 'touch abc' creates the empty file 'abc', and
'touch abc.exe' then creates 'abc.exe'.

And now, if you do a 'touch abc', the timestamp of the file 'abc' is
changed, and 'abc.exe' is left alone.

Back to Paul's problem, getting a list of the actual filenames, as they
actually exist in the filesystem, can be handled by 'find', I think.  At
least it worked in my simple test setup, above.

$ find . -name abc
./abc
$ find . -name 'abc*'
./abc
./abc.bat
./abc.exe
./abc.sh

Since find prints each file name on a line by itself, filenames with
spaces just "work":

$ touch 'pdq xyz'
$ find .
.
./abc
./abc.bat
./abc.exe
./abc.sh
./pdq xyz


To process the above output, use a 'while' loop with the 'read' command
and quote the shell variable in the loop body to preserve the single
filename with spaces:

$ find . |
> while read filenames
> do
>  file "$filenames"
> done
.: directory
./abc: empty
./abc.bat: empty
./abc.exe: empty
./abc.sh: empty
./pdq xyz: empty


The above is for illustration only.  It is not efficient, since 'file' is
run 6 times, when it could have run once with multiple file names, but
then the quoting wouild be more difficult.  You would replace it with 'ls
-l' to get individual file metadata, though again it would be inefficient.

Using 'xargs' would improve this, assuming the right parameters are used.
This will work with 'xargs' and 'cpio', I'm not sure which other commands
might support literal NULL termination of strings (note the 0 (zero) in
each command's args).

find . -print0 | xargs -0 file
.: directory
./abc: empty
./abc.bat: empty
./abc.exe: empty
./abc.sh: empty
./pdq xyz: empty


I hope this is helpful.

Bob


--
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