What would cause glob to list results twice? [on hold]

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP












6















System: Raspbian 8 on a Raspberry Pi 3



An errant space in a sudo command caused a bunch of system directories (/bin, /etc, /usr, etc.) to be moved into a subdirectory. I was able to fix it by putting the SD card in my laptop and using a commercial ext4 read/write driver to move the directories back, but since then, I've had this problem:



josh2112@jenna:/etc $ ls -l
<snip/>
drwxr-xr-x 3 root root 4096 Jul 29 2016 ifplugd
drwxr-xr-x 2 root root 4096 Nov 12 09:09 ImageMagick-6
drwxr-xr-x 2 root root 4096 Nov 12 09:09 ImageMagick-6
drwxr-xr-x 2 root root 4096 Dec 29 11:15 init
drwxr-xr-x 2 root root 4096 Dec 29 11:15 init
drwxr-xr-x 2 root root 4096 Dec 31 14:41 init.d
drwxr-xr-x 5 root root 4096 Sep 20 2017 initramfs-tools
drwxr-xr-x 5 root root 4096 Sep 20 2017 initramfs-tools
-rw-r--r-- 1 root root 1865 May 27 2016 inputrc
drwxr-xr-x 3 root root 4096 Jul 29 2016 insserv
-rw-r--r-- 1 root root 859 Dec 4 2012 insserv.conf
-rw-r--r-- 1 root root 859 Dec 4 2012 insserv.conf
drwxr-xr-x 2 root root 4096 Sep 20 2017 insserv.conf.d
drwxr-xr-x 2 root root 4096 Jul 29 2016 iproute2
-rw-r--r-- 1 root root 28 Jan 6 2015 issue
-rw-r--r-- 1 root root 28 Jan 6 2015 issue
-rw-r--r-- 1 root root 21 Jan 6 2015 issue.net
-rw-r--r-- 1 root root 21 Jan 6 2015 issue.net
drwxr-xr-x 2 root root 4096 Jul 29 2016 kbd
drwxr-xr-x 4 root root 4096 Jul 29 2016 kernel
drwxr-xr-x 2 root root 4096 Oct 1 15:45 ldap
-rw-r--r-- 1 root root 95742 Dec 29 11:16 ld.so.cache
<snip/>

josh2112@jenna:/etc $ ls -li issue.net
2097413 -rw-r--r-- 1 root root 21 Jan 6 2015 issue.net

josh2112@jenna:/etc $ ls -lbi issue.net*
2097413 -rw-r--r-- 1 root root 21 Jan 6 2015 issue.net
2097413 -rw-r--r-- 1 root root 21 Jan 6 2015 issue.net


Notice when I specify the name of the file directly I only see one copy, but when I use a star I see two copies. I printed the inode number to show that they're not two physically separate files?



Some more observations:



  • Not everything is duplicated, but it seems to be the majority of files and the majority of directories.

  • The duplicates match in every detail, including inode number.

  • This occurs in /etc only; the other directories that got moved then moved back appear fine.

  • I used the -b code to show any nonprintable chars in the filenames.

Any ideas?



Edit: Still not sure what caused the original issue but e2fsck found & fixed a ton of things, and the duplicate entries seem to be gone.



Edit 2: The duplicates are gone but the original are also gone That's on me, I guess, for blindly answering 'yes' to 400 or so e2fsck-reported errors. Meh, it was time for a reinstall anyway.



I guess the thing to be learned from all this is to use the proper tools for the job. Next time I'll try Tiny Core Linux which provides a "Live CD" type of environment via SD card, loaded into memory, so I can repair the SD card directly on the RPi.










share|improve this question















put on hold as off-topic by Stephen Kitt, Jeff Schaller, Mr Shunz, jimmij, Anthony Geoghegan 9 hours ago


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "Questions describing a problem that can't be reproduced and seemingly went away on its own (or went away when a typo was fixed) are off-topic as they are unlikely to help future readers." – Stephen Kitt, Jeff Schaller, Mr Shunz, jimmij, Anthony Geoghegan
If this question can be reworded to fit the rules in the help center, please edit the question.
















  • What shell are you using? if you believe globbing is the issue, can you use set -x (or equivalent) to see exactly how the command is being expanded?

    – steeldriver
    Jan 16 at 3:01






  • 1





    What does e2fsck think of the file system? This could be a bug in the ext4 driver you used.

    – Stephen Kitt
    Jan 16 at 5:00











  • @steeldriver bash. Great idea about set -x. It reveals that ls issue.net* expands to ls --color=auto issue.net issue.net!

    – josh2112
    Jan 16 at 14:41







  • 1





    @StephenKitt Wow. e2fsck found all kinds of problems -- bad block numbers, wrong reference counts, and some weird things like this: Entry 'python2.7' in ... (2097153) is a link to directory .../python2.7 (2098948). I will run an automatic repair when I can get back to the machine.

    – josh2112
    Jan 16 at 14:58











  • @josh2112 It would have been useful to post the results of the e2fsck as an answer so that it could help any future users who might have the same problem. As it stands, this (excellent) questions is likely to be closed as a problem that can't be reproduced. Don't be afraid to post (and accept) answers to your own questions: unix.stackexchange.com/help/self-answer

    – Anthony Geoghegan
    13 hours ago
















6















System: Raspbian 8 on a Raspberry Pi 3



An errant space in a sudo command caused a bunch of system directories (/bin, /etc, /usr, etc.) to be moved into a subdirectory. I was able to fix it by putting the SD card in my laptop and using a commercial ext4 read/write driver to move the directories back, but since then, I've had this problem:



josh2112@jenna:/etc $ ls -l
<snip/>
drwxr-xr-x 3 root root 4096 Jul 29 2016 ifplugd
drwxr-xr-x 2 root root 4096 Nov 12 09:09 ImageMagick-6
drwxr-xr-x 2 root root 4096 Nov 12 09:09 ImageMagick-6
drwxr-xr-x 2 root root 4096 Dec 29 11:15 init
drwxr-xr-x 2 root root 4096 Dec 29 11:15 init
drwxr-xr-x 2 root root 4096 Dec 31 14:41 init.d
drwxr-xr-x 5 root root 4096 Sep 20 2017 initramfs-tools
drwxr-xr-x 5 root root 4096 Sep 20 2017 initramfs-tools
-rw-r--r-- 1 root root 1865 May 27 2016 inputrc
drwxr-xr-x 3 root root 4096 Jul 29 2016 insserv
-rw-r--r-- 1 root root 859 Dec 4 2012 insserv.conf
-rw-r--r-- 1 root root 859 Dec 4 2012 insserv.conf
drwxr-xr-x 2 root root 4096 Sep 20 2017 insserv.conf.d
drwxr-xr-x 2 root root 4096 Jul 29 2016 iproute2
-rw-r--r-- 1 root root 28 Jan 6 2015 issue
-rw-r--r-- 1 root root 28 Jan 6 2015 issue
-rw-r--r-- 1 root root 21 Jan 6 2015 issue.net
-rw-r--r-- 1 root root 21 Jan 6 2015 issue.net
drwxr-xr-x 2 root root 4096 Jul 29 2016 kbd
drwxr-xr-x 4 root root 4096 Jul 29 2016 kernel
drwxr-xr-x 2 root root 4096 Oct 1 15:45 ldap
-rw-r--r-- 1 root root 95742 Dec 29 11:16 ld.so.cache
<snip/>

josh2112@jenna:/etc $ ls -li issue.net
2097413 -rw-r--r-- 1 root root 21 Jan 6 2015 issue.net

josh2112@jenna:/etc $ ls -lbi issue.net*
2097413 -rw-r--r-- 1 root root 21 Jan 6 2015 issue.net
2097413 -rw-r--r-- 1 root root 21 Jan 6 2015 issue.net


Notice when I specify the name of the file directly I only see one copy, but when I use a star I see two copies. I printed the inode number to show that they're not two physically separate files?



Some more observations:



  • Not everything is duplicated, but it seems to be the majority of files and the majority of directories.

  • The duplicates match in every detail, including inode number.

  • This occurs in /etc only; the other directories that got moved then moved back appear fine.

  • I used the -b code to show any nonprintable chars in the filenames.

Any ideas?



Edit: Still not sure what caused the original issue but e2fsck found & fixed a ton of things, and the duplicate entries seem to be gone.



Edit 2: The duplicates are gone but the original are also gone That's on me, I guess, for blindly answering 'yes' to 400 or so e2fsck-reported errors. Meh, it was time for a reinstall anyway.



I guess the thing to be learned from all this is to use the proper tools for the job. Next time I'll try Tiny Core Linux which provides a "Live CD" type of environment via SD card, loaded into memory, so I can repair the SD card directly on the RPi.










share|improve this question















put on hold as off-topic by Stephen Kitt, Jeff Schaller, Mr Shunz, jimmij, Anthony Geoghegan 9 hours ago


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "Questions describing a problem that can't be reproduced and seemingly went away on its own (or went away when a typo was fixed) are off-topic as they are unlikely to help future readers." – Stephen Kitt, Jeff Schaller, Mr Shunz, jimmij, Anthony Geoghegan
If this question can be reworded to fit the rules in the help center, please edit the question.
















  • What shell are you using? if you believe globbing is the issue, can you use set -x (or equivalent) to see exactly how the command is being expanded?

    – steeldriver
    Jan 16 at 3:01






  • 1





    What does e2fsck think of the file system? This could be a bug in the ext4 driver you used.

    – Stephen Kitt
    Jan 16 at 5:00











  • @steeldriver bash. Great idea about set -x. It reveals that ls issue.net* expands to ls --color=auto issue.net issue.net!

    – josh2112
    Jan 16 at 14:41







  • 1





    @StephenKitt Wow. e2fsck found all kinds of problems -- bad block numbers, wrong reference counts, and some weird things like this: Entry 'python2.7' in ... (2097153) is a link to directory .../python2.7 (2098948). I will run an automatic repair when I can get back to the machine.

    – josh2112
    Jan 16 at 14:58











  • @josh2112 It would have been useful to post the results of the e2fsck as an answer so that it could help any future users who might have the same problem. As it stands, this (excellent) questions is likely to be closed as a problem that can't be reproduced. Don't be afraid to post (and accept) answers to your own questions: unix.stackexchange.com/help/self-answer

    – Anthony Geoghegan
    13 hours ago














6












6








6


1






System: Raspbian 8 on a Raspberry Pi 3



An errant space in a sudo command caused a bunch of system directories (/bin, /etc, /usr, etc.) to be moved into a subdirectory. I was able to fix it by putting the SD card in my laptop and using a commercial ext4 read/write driver to move the directories back, but since then, I've had this problem:



josh2112@jenna:/etc $ ls -l
<snip/>
drwxr-xr-x 3 root root 4096 Jul 29 2016 ifplugd
drwxr-xr-x 2 root root 4096 Nov 12 09:09 ImageMagick-6
drwxr-xr-x 2 root root 4096 Nov 12 09:09 ImageMagick-6
drwxr-xr-x 2 root root 4096 Dec 29 11:15 init
drwxr-xr-x 2 root root 4096 Dec 29 11:15 init
drwxr-xr-x 2 root root 4096 Dec 31 14:41 init.d
drwxr-xr-x 5 root root 4096 Sep 20 2017 initramfs-tools
drwxr-xr-x 5 root root 4096 Sep 20 2017 initramfs-tools
-rw-r--r-- 1 root root 1865 May 27 2016 inputrc
drwxr-xr-x 3 root root 4096 Jul 29 2016 insserv
-rw-r--r-- 1 root root 859 Dec 4 2012 insserv.conf
-rw-r--r-- 1 root root 859 Dec 4 2012 insserv.conf
drwxr-xr-x 2 root root 4096 Sep 20 2017 insserv.conf.d
drwxr-xr-x 2 root root 4096 Jul 29 2016 iproute2
-rw-r--r-- 1 root root 28 Jan 6 2015 issue
-rw-r--r-- 1 root root 28 Jan 6 2015 issue
-rw-r--r-- 1 root root 21 Jan 6 2015 issue.net
-rw-r--r-- 1 root root 21 Jan 6 2015 issue.net
drwxr-xr-x 2 root root 4096 Jul 29 2016 kbd
drwxr-xr-x 4 root root 4096 Jul 29 2016 kernel
drwxr-xr-x 2 root root 4096 Oct 1 15:45 ldap
-rw-r--r-- 1 root root 95742 Dec 29 11:16 ld.so.cache
<snip/>

josh2112@jenna:/etc $ ls -li issue.net
2097413 -rw-r--r-- 1 root root 21 Jan 6 2015 issue.net

josh2112@jenna:/etc $ ls -lbi issue.net*
2097413 -rw-r--r-- 1 root root 21 Jan 6 2015 issue.net
2097413 -rw-r--r-- 1 root root 21 Jan 6 2015 issue.net


Notice when I specify the name of the file directly I only see one copy, but when I use a star I see two copies. I printed the inode number to show that they're not two physically separate files?



Some more observations:



  • Not everything is duplicated, but it seems to be the majority of files and the majority of directories.

  • The duplicates match in every detail, including inode number.

  • This occurs in /etc only; the other directories that got moved then moved back appear fine.

  • I used the -b code to show any nonprintable chars in the filenames.

Any ideas?



Edit: Still not sure what caused the original issue but e2fsck found & fixed a ton of things, and the duplicate entries seem to be gone.



Edit 2: The duplicates are gone but the original are also gone That's on me, I guess, for blindly answering 'yes' to 400 or so e2fsck-reported errors. Meh, it was time for a reinstall anyway.



I guess the thing to be learned from all this is to use the proper tools for the job. Next time I'll try Tiny Core Linux which provides a "Live CD" type of environment via SD card, loaded into memory, so I can repair the SD card directly on the RPi.










share|improve this question
















System: Raspbian 8 on a Raspberry Pi 3



An errant space in a sudo command caused a bunch of system directories (/bin, /etc, /usr, etc.) to be moved into a subdirectory. I was able to fix it by putting the SD card in my laptop and using a commercial ext4 read/write driver to move the directories back, but since then, I've had this problem:



josh2112@jenna:/etc $ ls -l
<snip/>
drwxr-xr-x 3 root root 4096 Jul 29 2016 ifplugd
drwxr-xr-x 2 root root 4096 Nov 12 09:09 ImageMagick-6
drwxr-xr-x 2 root root 4096 Nov 12 09:09 ImageMagick-6
drwxr-xr-x 2 root root 4096 Dec 29 11:15 init
drwxr-xr-x 2 root root 4096 Dec 29 11:15 init
drwxr-xr-x 2 root root 4096 Dec 31 14:41 init.d
drwxr-xr-x 5 root root 4096 Sep 20 2017 initramfs-tools
drwxr-xr-x 5 root root 4096 Sep 20 2017 initramfs-tools
-rw-r--r-- 1 root root 1865 May 27 2016 inputrc
drwxr-xr-x 3 root root 4096 Jul 29 2016 insserv
-rw-r--r-- 1 root root 859 Dec 4 2012 insserv.conf
-rw-r--r-- 1 root root 859 Dec 4 2012 insserv.conf
drwxr-xr-x 2 root root 4096 Sep 20 2017 insserv.conf.d
drwxr-xr-x 2 root root 4096 Jul 29 2016 iproute2
-rw-r--r-- 1 root root 28 Jan 6 2015 issue
-rw-r--r-- 1 root root 28 Jan 6 2015 issue
-rw-r--r-- 1 root root 21 Jan 6 2015 issue.net
-rw-r--r-- 1 root root 21 Jan 6 2015 issue.net
drwxr-xr-x 2 root root 4096 Jul 29 2016 kbd
drwxr-xr-x 4 root root 4096 Jul 29 2016 kernel
drwxr-xr-x 2 root root 4096 Oct 1 15:45 ldap
-rw-r--r-- 1 root root 95742 Dec 29 11:16 ld.so.cache
<snip/>

josh2112@jenna:/etc $ ls -li issue.net
2097413 -rw-r--r-- 1 root root 21 Jan 6 2015 issue.net

josh2112@jenna:/etc $ ls -lbi issue.net*
2097413 -rw-r--r-- 1 root root 21 Jan 6 2015 issue.net
2097413 -rw-r--r-- 1 root root 21 Jan 6 2015 issue.net


Notice when I specify the name of the file directly I only see one copy, but when I use a star I see two copies. I printed the inode number to show that they're not two physically separate files?



Some more observations:



  • Not everything is duplicated, but it seems to be the majority of files and the majority of directories.

  • The duplicates match in every detail, including inode number.

  • This occurs in /etc only; the other directories that got moved then moved back appear fine.

  • I used the -b code to show any nonprintable chars in the filenames.

Any ideas?



Edit: Still not sure what caused the original issue but e2fsck found & fixed a ton of things, and the duplicate entries seem to be gone.



Edit 2: The duplicates are gone but the original are also gone That's on me, I guess, for blindly answering 'yes' to 400 or so e2fsck-reported errors. Meh, it was time for a reinstall anyway.



I guess the thing to be learned from all this is to use the proper tools for the job. Next time I'll try Tiny Core Linux which provides a "Live CD" type of environment via SD card, loaded into memory, so I can repair the SD card directly on the RPi.







ls wildcards






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 9 hours ago







josh2112

















asked Jan 15 at 23:39









josh2112josh2112

1312




1312




put on hold as off-topic by Stephen Kitt, Jeff Schaller, Mr Shunz, jimmij, Anthony Geoghegan 9 hours ago


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "Questions describing a problem that can't be reproduced and seemingly went away on its own (or went away when a typo was fixed) are off-topic as they are unlikely to help future readers." – Stephen Kitt, Jeff Schaller, Mr Shunz, jimmij, Anthony Geoghegan
If this question can be reworded to fit the rules in the help center, please edit the question.







put on hold as off-topic by Stephen Kitt, Jeff Schaller, Mr Shunz, jimmij, Anthony Geoghegan 9 hours ago


This question appears to be off-topic. The users who voted to close gave this specific reason:


  • "Questions describing a problem that can't be reproduced and seemingly went away on its own (or went away when a typo was fixed) are off-topic as they are unlikely to help future readers." – Stephen Kitt, Jeff Schaller, Mr Shunz, jimmij, Anthony Geoghegan
If this question can be reworded to fit the rules in the help center, please edit the question.












  • What shell are you using? if you believe globbing is the issue, can you use set -x (or equivalent) to see exactly how the command is being expanded?

    – steeldriver
    Jan 16 at 3:01






  • 1





    What does e2fsck think of the file system? This could be a bug in the ext4 driver you used.

    – Stephen Kitt
    Jan 16 at 5:00











  • @steeldriver bash. Great idea about set -x. It reveals that ls issue.net* expands to ls --color=auto issue.net issue.net!

    – josh2112
    Jan 16 at 14:41







  • 1





    @StephenKitt Wow. e2fsck found all kinds of problems -- bad block numbers, wrong reference counts, and some weird things like this: Entry 'python2.7' in ... (2097153) is a link to directory .../python2.7 (2098948). I will run an automatic repair when I can get back to the machine.

    – josh2112
    Jan 16 at 14:58











  • @josh2112 It would have been useful to post the results of the e2fsck as an answer so that it could help any future users who might have the same problem. As it stands, this (excellent) questions is likely to be closed as a problem that can't be reproduced. Don't be afraid to post (and accept) answers to your own questions: unix.stackexchange.com/help/self-answer

    – Anthony Geoghegan
    13 hours ago


















  • What shell are you using? if you believe globbing is the issue, can you use set -x (or equivalent) to see exactly how the command is being expanded?

    – steeldriver
    Jan 16 at 3:01






  • 1





    What does e2fsck think of the file system? This could be a bug in the ext4 driver you used.

    – Stephen Kitt
    Jan 16 at 5:00











  • @steeldriver bash. Great idea about set -x. It reveals that ls issue.net* expands to ls --color=auto issue.net issue.net!

    – josh2112
    Jan 16 at 14:41







  • 1





    @StephenKitt Wow. e2fsck found all kinds of problems -- bad block numbers, wrong reference counts, and some weird things like this: Entry 'python2.7' in ... (2097153) is a link to directory .../python2.7 (2098948). I will run an automatic repair when I can get back to the machine.

    – josh2112
    Jan 16 at 14:58











  • @josh2112 It would have been useful to post the results of the e2fsck as an answer so that it could help any future users who might have the same problem. As it stands, this (excellent) questions is likely to be closed as a problem that can't be reproduced. Don't be afraid to post (and accept) answers to your own questions: unix.stackexchange.com/help/self-answer

    – Anthony Geoghegan
    13 hours ago

















What shell are you using? if you believe globbing is the issue, can you use set -x (or equivalent) to see exactly how the command is being expanded?

– steeldriver
Jan 16 at 3:01





What shell are you using? if you believe globbing is the issue, can you use set -x (or equivalent) to see exactly how the command is being expanded?

– steeldriver
Jan 16 at 3:01




1




1





What does e2fsck think of the file system? This could be a bug in the ext4 driver you used.

– Stephen Kitt
Jan 16 at 5:00





What does e2fsck think of the file system? This could be a bug in the ext4 driver you used.

– Stephen Kitt
Jan 16 at 5:00













@steeldriver bash. Great idea about set -x. It reveals that ls issue.net* expands to ls --color=auto issue.net issue.net!

– josh2112
Jan 16 at 14:41






@steeldriver bash. Great idea about set -x. It reveals that ls issue.net* expands to ls --color=auto issue.net issue.net!

– josh2112
Jan 16 at 14:41





1




1





@StephenKitt Wow. e2fsck found all kinds of problems -- bad block numbers, wrong reference counts, and some weird things like this: Entry 'python2.7' in ... (2097153) is a link to directory .../python2.7 (2098948). I will run an automatic repair when I can get back to the machine.

– josh2112
Jan 16 at 14:58





@StephenKitt Wow. e2fsck found all kinds of problems -- bad block numbers, wrong reference counts, and some weird things like this: Entry 'python2.7' in ... (2097153) is a link to directory .../python2.7 (2098948). I will run an automatic repair when I can get back to the machine.

– josh2112
Jan 16 at 14:58













@josh2112 It would have been useful to post the results of the e2fsck as an answer so that it could help any future users who might have the same problem. As it stands, this (excellent) questions is likely to be closed as a problem that can't be reproduced. Don't be afraid to post (and accept) answers to your own questions: unix.stackexchange.com/help/self-answer

– Anthony Geoghegan
13 hours ago






@josh2112 It would have been useful to post the results of the e2fsck as an answer so that it could help any future users who might have the same problem. As it stands, this (excellent) questions is likely to be closed as a problem that can't be reproduced. Don't be afraid to post (and accept) answers to your own questions: unix.stackexchange.com/help/self-answer

– Anthony Geoghegan
13 hours ago











0






active

oldest

votes

















0






active

oldest

votes








0






active

oldest

votes









active

oldest

votes






active

oldest

votes

Popular posts from this blog

How to check contact read email or not when send email to Individual?

Bahrain

Postfix configuration issue with fips on centos 7; mailgun relay