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/code-file_attribs.sas -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/dup_kycid_work_items.sas -rwxrwx--- 1 pb82477 kycmis 524288 Jan 7 12:23 /kyc_mis/dev/code/paul/emp_dob.sas7bdat ... /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 cmr_error_reject_reports.sas -rwxrwx--- 1 pb82477 kycmis 2477 Oct 17 14:49 cmr_excep_info_rejects_fieldlengths.sas -rwxrwx--- 1 pb82477 kycmis 1658 Oct 22 14:32 cmr_excep_info_rejects.sas 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. Paul Bartells [email protected] 972-655-0072 -----Original Message----- From: [kylheku.com] Kaz Kylheku (Coreutils) <[email protected]> Sent: Wednesday, March 20, 2019 6:34 PM To: Bartells, Paul [GCB-CARDS NE] <[email protected]> Cc: '[email protected]' <[email protected]>; coreutils <[email protected]> Subject: Re: Possible ls bug? On 2019-02-26 13:10, Bartells, Paul wrote: > I have encountered behavior with ls -R that appears to be incongruous. > My actual command line entry is: ls -alR /kyc_mis/dev/*/*/paul/* > > pauldev.lst. [ ... ] > /kyc_mis/dev/rpts/paul/kyc: > total 599 > -rwxrwx--- 1 pb82477 kycmis 262144 Oct 31 17:06 > kyc_excepreport_old_20181022.sas7bdat > drwxrwx--- 10 pb82477 kycmis 176 Oct 24 16:14 .. > drwxrwx--- 2 pb82477 kycmis 55 Oct 31 17:06 . What is odd here is that name of the directory being listed doesn't match the pattern /kyc_mis/dev/*/*/paul/ (assuming we can trust that line of the output to be true: ls is really listing a directory by that name). It has a "kyc" component where the pattern expects "paul". You haven't told "ls" to follow symlinks, either. Unless the filesystem has cycles, or ls has started following ".." links, we should not be ending up in this directory from any starting point that matches the command line pattern. Paul Bartells [email protected] 972-655-0072 -----Original Message----- From: [kylheku.com] Kaz Kylheku (Coreutils) <[email protected]> Sent: Wednesday, March 20, 2019 6:34 PM To: Bartells, Paul [GCB-CARDS NE] <[email protected]> Cc: '[email protected]' <[email protected]>; coreutils <[email protected]> Subject: Re: Possible ls bug? On 2019-02-26 13:10, Bartells, Paul wrote: > I have encountered behavior with ls -R that appears to be incongruous. > My actual command line entry is: ls -alR /kyc_mis/dev/*/*/paul/* > > pauldev.lst. [ ... ] > /kyc_mis/dev/rpts/paul/kyc: > total 599 > -rwxrwx--- 1 pb82477 kycmis 262144 Oct 31 17:06 > kyc_excepreport_old_20181022.sas7bdat > drwxrwx--- 10 pb82477 kycmis 176 Oct 24 16:14 .. > drwxrwx--- 2 pb82477 kycmis 55 Oct 31 17:06 . What is odd here is that name of the directory being listed doesn't match the pattern /kyc_mis/dev/*/*/paul/ (assuming we can trust that line of the output to be true: ls is really listing a directory by that name). It has a "kyc" component where the pattern expects "paul". You haven't told "ls" to follow symlinks, either. Unless the filesystem has cycles, or ls has started following ".." links, we should not be ending up in this directory from any starting point that matches the command line pattern.
