Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

how should glob type modifiers behave with respect to symlinks #1603

Open
krader1961 opened this issue Aug 31, 2022 · 1 comment
Open

how should glob type modifiers behave with respect to symlinks #1603

krader1961 opened this issue Aug 31, 2022 · 1 comment

Comments

@krader1961
Copy link
Contributor

My fix for issue #1240 (broken symlink handling short-circuits glob expansion) had the unexpected, at least by me, side-effect of changing the behavior of examples like this:

> mkdir d
> ln -s d s
> echo *[type:dir]
d

Prior to my fix (PR #1567) that would output both d and s. My fix causes it to only output d. See this comment thread for more context. I believe it should output both d and s while @xiaq believes, at least as I write this, that the symlink above should be treated as a regular file. This is their comment from the 0.19.0-release-notes.md file:

-   Symbolic links are now always treated as ordinary files by the global
    modifiers `type:dir` and `type:regular` in wildcard expansions.

However, that isn't actually the behavior. If that was the behavior then this would output both file1 and file2:

> touch file1
> ln -s /invalid/path file2
> echo *[type:regular]
file1

The symlink is neither a regular file or directory regardless of the filesystem object it points to.

Even worse is that globs expanded without a modifier do not match symlinks (these symlinks are from prior experiments in my ~/tmp directory):

> ls -lhtr
lrwxr-x--- 1 krader staff 13 Aug 30 20:19 file2 -> /invalid/path
lrwxr-x--- 1 krader staff  5 Aug 30 20:20 file3 -> file1
lrwxr-x--- 1 krader staff  1 Aug 30 20:31 s -> d
> rm *
Exception: wildcard has no match
[tty 94], line 1: rm *

This was broken before my "fix" because broken symlinks short-circuited glob expansion. Which means the new behavior is equivalent to the old behavior. However, I would argue that absent a glob modifier those symlinks should be included in the files matching the glob.

@Ultra-Code
Copy link
Contributor

Ultra-Code commented Mar 24, 2024

Having a similar issue as described by @krader1961

❯ l /sys/devices/system/cpu/cpu?/cpufreq/scaling_governor

13137 -rw-r--r-- 1 root root 4.0K Mar 24 07:03 /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
13154 -rw-r--r-- 1 root root 4.0K Mar 24 07:03 /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
13171 -rw-r--r-- 1 root root 4.0K Mar 24 07:03 /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor
13188 -rw-r--r-- 1 root root 4.0K Mar 24 07:03 /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor

As expected cpu0 is available

❯ l /sys/devices/system/cpu/cpu0
total 0
12338 drwxr-xr-x  6 root root    0 Mar 24 07:47 cache/
13141 lrwxrwxrwx  1 root root    0 Mar 24 05:38 cpufreq -> ../cpufreq/policy0/
 9342 drwxr-xr-x 11 root root    0 Mar 24 07:47 cpuidle/
 1831 -r--------  1 root root 4.0K Mar 24 07:47 crash_notes
 1832 -r--------  1 root root 4.0K Mar 24 07:47 crash_notes_size
10166 lrwxrwxrwx  1 root root    0 Mar 24 07:47 driver -> ../../../../bus/cpu/drivers/processor/
 5617 lrwxrwxrwx  1 root root    0 Mar 24 07:47 firmware_node -> ../../../LNXSYSTM:00/LNXCPU:00/
 8767 drwxr-xr-x  2 root root    0 Mar 24 07:47 hotplug/
13814 drwxr-xr-x  2 root root    0 Mar 24 07:47 microcode/
 1842 lrwxrwxrwx  1 root root    0 Mar 24 07:47 node0 -> ../../node/node0/
 1835 drwxr-xr-x  2 root root    0 Mar 24 07:47 power/
 1834 lrwxrwxrwx  1 root root    0 Mar 24 05:38 subsystem -> ../../../../bus/cpu/
13093 drwxr-xr-x  2 root root    0 Mar 24 07:47 thermal_throttle/
12270 drwxr-xr-x  2 root root    0 Mar 24 07:47 topology/
 1830 -rw-r--r--  1 root root 4.0K Mar 24 07:47 uevent

Note: cpufreq is a symlink but works in this case
However

❯ l /sys/class/scsi_host/host?/link_power_management_policy
Exception: wildcard has no match
 [tty 4]:1:3-57: l /sys/class/scsi_host/host?/link_power_management_policy
 
❯ l /sys/class/scsi_host/host0
12793 lrwxrwxrwx 1 root root 0 Mar 24 05:38 /sys/class/scsi_host/host0 -> ../../devices/pci0000:00/0000:00:17.0/ata1/host0/scsi_host/host0/

Accessing any property of /sys/class/scsi_host/host?give the same error

While the driver attribute of cpu0 works even though it is multiple back relative symlinks

❯ l /sys/devices/system/cpu/cpu?/driver/uevent
10234 --w------- 1 root root 4.0K Mar 24 05:38 /sys/devices/system/cpu/cpu0/driver/uevent
10234 --w------- 1 root root 4.0K Mar 24 07:52 /sys/devices/system/cpu/cpu1/driver/uevent
10234 --w------- 1 root root 4.0K Mar 24 07:52 /sys/devices/system/cpu/cpu2/driver/uevent
10234 --w------- 1 root root 4.0K Mar 24 07:52 /sys/devices/system/cpu/cpu3/driver/uevent

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants