[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Possible ls bug?
From: |
Bartells, Paul |
Subject: |
RE: Possible ls bug? |
Date: |
Thu, 21 Mar 2019 16:43:12 +0000 |
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