5 ms·

Really? I think it's fantastic to have access to that kind of information from my shell. I've certainly used it for debugging live systems. Sure I could stil

by d23 6y ago

Really? I think it's fantastic to have access to that kind of information from my shell. I've certainly used it for debugging live systems. Sure I could still use something like lsof and have it monkey around with the extra syscalls, but it's just really cool and useful to be able to use it with one less binary.

jbverschoor 6y ago
Is rather have proper object interface to work with. Saves a lot of parsing
- viraptor 6y ago
  You could have object interface on procfs. I think Solaris used a lot of binary files there.
- bayindirh 6y ago
  Hacking a small pipeline starting with cat always beats having to write a code to parse something unintelligible at first sight IMHO. At the end of the day, first one is always faster.
  - jbverschoor 6y ago
    Streams should be used for that.. streams. Structures should be used for structured data.
    - bayindirh 6y ago
      I don't see a reason for /proc/meminfo or /proc/cpuinfo to be a stream. Similarly /proc/$pid/{cmdline,cgroup,mounts,..} to be streams. /proc is a very fine interface for getting realtime basic information about a process. Maybe we should leave it as it is and stop abusing well matured interfaces? I see red when Chrome uses intentionally broken symbolic links to store information on a system for example.
Galanwe 6y ago
It's not really harmful as long as it's just some shell programs here and there that use it. The problem is when everything starts to rely on it. Hell, in linux, the dynamic linker (ld-linux.so) depends on procfs to expands ELF variables (e.g. $ORIGIN, which requires the path to the current program being executed, which is retrieved from procfs). It's gone _way_ too far! Now it does not mean that an other interface would be ugly/annoying to use from the shell. `sysctl` for instance is quite convenient to use from the shell, and the hierarchical variables that it accepts could very well mirror what procfs exposes. Something like `$ sysctl proc.42.environ` <=> `$ cat /proc/42/environ`
- gbrown_ 6y ago
  I feel Solaris really got this right with its p* commands, e.g. pargs -e 42 or just penv 42 to mirror your example. Whilst in practice they may use a procfs they could use other backends if implemented on other systems without or with a differing procfs. These commands are a much cleaner interface IMHO.

by d23 6y ago

jbverschoor 6y ago

Is rather have proper object interface to work with. Saves a lot of parsing

viraptor 6y ago
You could have object interface on procfs. I think Solaris used a lot of binary files there.
bayindirh 6y ago
Hacking a small pipeline starting with cat always beats having to write a code to parse something unintelligible at first sight IMHO. At the end of the day, first one is always faster.
- jbverschoor 6y ago
  Streams should be used for that.. streams. Structures should be used for structured data.
  - bayindirh 6y ago
    I don't see a reason for /proc/meminfo or /proc/cpuinfo to be a stream. Similarly /proc/$pid/{cmdline,cgroup,mounts,..} to be streams. /proc is a very fine interface for getting realtime basic information about a process. Maybe we should leave it as it is and stop abusing well matured interfaces? I see red when Chrome uses intentionally broken symbolic links to store information on a system for example.

Galanwe 6y ago

It's not really harmful as long as it's just some shell programs here and there that use it. The problem is when everything starts to rely on it. Hell, in linux, the dynamic linker (ld-linux.so) depends on procfs to expands ELF variables (e.g. $ORIGIN, which requires the path to the current program being executed, which is retrieved from procfs). It's gone _way_ too far! Now it does not mean that an other interface would be ugly/annoying to use from the shell. `sysctl` for instance is quite convenient to use from the shell, and the hierarchical variables that it accepts could very well mirror what procfs exposes. Something like `$ sysctl proc.42.environ` <=> `$ cat /proc/42/environ`

gbrown_ 6y ago
I feel Solaris really got this right with its p* commands, e.g. pargs -e 42 or just penv 42 to mirror your example. Whilst in practice they may use a procfs they could use other backends if implemented on other systems without or with a differing procfs. These commands are a much cleaner interface IMHO.