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 [email protected] 972-655-0072 -----Original Message----- From: [External] Erik Auerswald <[email protected]> Sent: Thursday, March 21, 2019 11:17 AM To: Bartells, Paul [GCB-CARDS NE] <[email protected]> Cc: Kaz Kylheku (Coreutils) <[email protected]>; coreutils <[email protected]>; '[email protected]' <[email protected]> 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
