RE: Possible ls bug?

[Bartells, Paul]

Erik, thank you. Find provided what I was looking for. 

By the way, I don't know how those URLs appeared. They didn't show on my screen 
or in the message I sent. It may be that corporate security scanning did 
something before it was actually transmitted. 

Paul Bartells
address@hidden
972-655-0072



-----Original Message-----
From: [External] Erik Auerswald <address@hidden> 
Sent: Thursday, March 21, 2019 11:17 AM
To: Bartells, Paul [GCB-CARDS NE] <address@hidden>
Cc: Kaz Kylheku (Coreutils) <address@hidden>; coreutils 
<coreutils-bounces+962-396-1872=address@hidden>; 'address@hidden' 
<address@hidden>
Subject: Re: Possible ls bug?

Hello Paul,

On Thu, Mar 21, 2019 at 03:46:28PM +0000, Bartells, Paul  wrote:
> Thanks for responding, Kaz. What you observed is true. There is a disconnect 
> between the command line and the listing I provided. Apparently I picked up 
> the wrong listing. There was an extra "/*" in the command line I showed. It 
> should have been ls -alR /kyc_mis/dev/*/paul/*. Please accept my apologies.
> 
> Here is a more accurate listing example:
> The first format is exactly what I have been trying to find with no success 
> up to this point. My issue is that all the subsequent directory listings do 
> not continue that format.
> 
> ls -alR /kyc_mis/dev/*/paul/* > coreutils_example.txt <<< partial 
> listing of coreutils_example.txt >>>
> -rwxrwx--- 1 pb82477 kycmis      28744 Dec 12 13:54 
> /kyc_mis/dev/code/paul/alternate
> -rwxrwx--- 1 pb82477 kycmis       1467 Dec 19 15:21 
> /kyc_mis/dev/code/paul/https://urldefense.proofpoint.com/v2/url?u=http-3A__code-2Dfile-5Fattribs.sas&d=DwIBAg&c=j-EkbjBYwkAB4f8ZbVn1Fw&r=ai4wCj25ojO-gtvGlmo7-DEriYa7TLnYclhePcbBR_A&m=js2pgycTMSF2Vnxkb6Zv7KymKhg-Ri79JiEAUyAIm_E&s=-yFPjeyVrd7B0-tF7o-UAb9i8sz4zooNYDNlw_AN35E&e=
> -rwxrwx--- 1 pb82477 kycmis     393216 Jan  7 13:30 
> /kyc_mis/dev/code/paul/dqip_dev_exc_list.sas7bdat
> -rwxrwx--- 1 pb82477 kycmis        214 Nov 14 14:54 
> /kyc_mis/dev/code/paul/https://urldefense.proofpoint.com/v2/url?u=http-3A__dup-5Fkycid-5Fwork-5Fitems.sas&d=DwIBAg&c=j-EkbjBYwkAB4f8ZbVn1Fw&r=ai4wCj25ojO-gtvGlmo7-DEriYa7TLnYclhePcbBR_A&m=js2pgycTMSF2Vnxkb6Zv7KymKhg-Ri79JiEAUyAIm_E&s=cB8u9UZrOtEZYP6o0bFoXZOO6syALu3lbvLmSgGSVBU&e=
> -rwxrwx--- 1 pb82477 kycmis     524288 Jan  7 12:23 
> /kyc_mis/dev/code/paul/emp_dob.sas7bdat
> ...

The first listing shows files that match the glob pattern.

> /kyc_mis/dev/code/paul/cmr:
> total 17125
> drwxrwx---  6 pb82477 kycmis   2631 Dec  7 13:57 .
> drwxrwx--- 16 kycmis  kycmis   1417 Feb 11 11:47 ..
> -rw-rw----  1 pb82477 kycmis  59013 Nov  5 13:28 
> cmr_error_reject_reports.log
> -rwxrwx---  1 pb82477 kycmis  12445 Nov  5 13:46 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__cmr-5Ferror-5Freject-5Freports.sas&d=DwIBAg&c=j-EkbjBYwkAB4f8ZbVn1Fw&r=ai4wCj25ojO-gtvGlmo7-DEriYa7TLnYclhePcbBR_A&m=js2pgycTMSF2Vnxkb6Zv7KymKhg-Ri79JiEAUyAIm_E&s=eOWlT0EyptD_tNIlTO2HjeZVY4mOb-62y7wHL9e6RRI&e=
> -rwxrwx---  1 pb82477 kycmis   2477 Oct 17 14:49 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__cmr-5Fexcep-5Finfo-5Frejects-5Ffieldlengths.sas&d=DwIBAg&c=j-EkbjBYwkAB4f8ZbVn1Fw&r=ai4wCj25ojO-gtvGlmo7-DEriYa7TLnYclhePcbBR_A&m=js2pgycTMSF2Vnxkb6Zv7KymKhg-Ri79JiEAUyAIm_E&s=RmmHpXAxJQ_tP_Wgs0wVCKTF0EupoVS3mx1HPeI3d7k&e=
> -rwxrwx---  1 pb82477 kycmis   1658 Oct 22 14:32 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__cmr-5Fexcep-5Finfo-5Frejects.sas&d=DwIBAg&c=j-EkbjBYwkAB4f8ZbVn1Fw&r=ai4wCj25ojO-gtvGlmo7-DEriYa7TLnYclhePcbBR_A&m=js2pgycTMSF2Vnxkb6Zv7KymKhg-Ri79JiEAUyAIm_E&s=KXzvhdEB97nahHQV_eLrbFgB0sDQ6rYeYPqpNk3Sg_0&e=

The second listing shows the contents of a directory that matches the glob 
pattern. Directories inside those directories will be shown in the same format, 
because you used the '-R' option of ls.

> However, even though the original listing wasn't the right one, it still 
> illustrates the problem. With the command "ls -alR", only the first directory 
> listed in the output shows the full path and filename on the right side. 
> Perhaps there is a better way to produce such a list, but this was the best 
> I've been able to come up with. I don't understand why the listing format 
> would change when going from a parent folder to its children.
> 
> Whether or not this is a bug, though, my objective is to produce a recursive, 
> long line, all files listing of a given tree, ultimately written to a file. 
> Perhaps that question could be answered? The behavior I noticed with ls still 
> doesn't make sense to me, but I can live with that. All I really need is some 
> way to accomplish my objective of producing that listing to be used in some 
> analytic research.
> 
> Any thoughts about this would be appreciated. I am open to suggestions. 
> Thanks.

You could consider using 'find' instead of 'ls':

    find /kyc_mis/dev/*/paul/ -ls

Thanks,
Erik
--
Always use the right tool for the job.
                        -- Rob Pike