RE: Possible ls bug?

[Bartells, Paul]

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
address@hidden
972-655-0072


-----Original Message-----
From: [kylheku.com] Kaz Kylheku (Coreutils) <address@hidden> 
Sent: Wednesday, March 20, 2019 6:34 PM
To: Bartells, Paul [GCB-CARDS NE] <address@hidden>
Cc: 'address@hidden' <address@hidden>; coreutils 
<coreutils-bounces+962-396-1872=address@hidden>
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
address@hidden
972-655-0072



-----Original Message-----
From: [kylheku.com] Kaz Kylheku (Coreutils) <address@hidden> 
Sent: Wednesday, March 20, 2019 6:34 PM
To: Bartells, Paul [GCB-CARDS NE] <address@hidden>
Cc: 'address@hidden' <address@hidden>; coreutils 
<coreutils-bounces+962-396-1872=address@hidden>
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.