What would cause glob to list results twice? [on hold]
Clash Royale CLAN TAG#URR8PPP
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
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
|
show 2 more comments
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
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
What shell are you using? if you believe globbing is the issue, can you useset -x
(or equivalent) to see exactly how the command is being expanded?
– steeldriver
Jan 16 at 3:01
1
What doese2fsck
think of the file system? This could be a bug in the ext4 driver you used.
– Stephen Kitt
Jan 16 at 5:00
@steeldriverbash
. Great idea aboutset -x
. It reveals thatls issue.net*
expands tols --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 thee2fsck
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
|
show 2 more comments
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
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
ls wildcards
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
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
What shell are you using? if you believe globbing is the issue, can you useset -x
(or equivalent) to see exactly how the command is being expanded?
– steeldriver
Jan 16 at 3:01
1
What doese2fsck
think of the file system? This could be a bug in the ext4 driver you used.
– Stephen Kitt
Jan 16 at 5:00
@steeldriverbash
. Great idea aboutset -x
. It reveals thatls issue.net*
expands tols --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 thee2fsck
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
|
show 2 more comments
What shell are you using? if you believe globbing is the issue, can you useset -x
(or equivalent) to see exactly how the command is being expanded?
– steeldriver
Jan 16 at 3:01
1
What doese2fsck
think of the file system? This could be a bug in the ext4 driver you used.
– Stephen Kitt
Jan 16 at 5:00
@steeldriverbash
. Great idea aboutset -x
. It reveals thatls issue.net*
expands tols --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 thee2fsck
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
|
show 2 more comments
0
active
oldest
votes
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
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 aboutset -x
. It reveals thatls issue.net*
expands tols --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