2 ms·

Wait. Is the problem here extra _text_ in the output that shouldn't be parsed? I cannot believe people are parsing text output from other commands in the year

Wait. Is the problem here extra _text_ in the output that shouldn't be parsed? I cannot believe people are parsing text output from other commands in the year 2021. To me that this sounds like incredibly unsafe practice and am just astounded it happens.

richardwhiuk 5y ago
Parsing the bytestream output of another program is the unix way.
- sixothree 5y ago
  I get that. I'm just surprised it's still considered acceptable. I feel like even simple JSON would be a better output. Sure, humans would have a problem reading it but that's what shells are for.
  - Spivak 5y ago
    That JSON would be the text output of the command. There are utilities like grep, find, sed, awk, git porcelain, readlink, basedir, which, that write output suitable for machines on stdout and other utilities that write output suitable for humans. If you want to be a good UNIX netizen then stdout is for machines while stderr is for humans.
anonydsfsfs 5y ago
I've seen this happen as a workaround for the following bug in Dash: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874264 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874264 If Dash was POSIX compliant, this wouldn't be necessary, but it isn't, so hacky text parsing is sadly necessary.
deleted 5y ago
[deleted]
kayodelycaon 5y ago
> I cannot believe people are parsing text output from other commands in the year 2021 If you're writing shell scripts, there aren't any other options. Here's a lovely little snippet to find the current wifi network for a reMarkable 2. If it's "Aardvark", it runs rsync. :) iw wlan0 info | grep -Po '(?<=ssid ).*' | tr -d '\n' Ugly as hell? Yes, but what's the alternative? Parsing text from a command is a headache, but it works most of the time. There often isn't an API or syscall to get the data you need on a specific system. My favorite ugly hack is having a Ruby on Rails application write a file to disk so it can be processed by another program using a shell and then picking up the output file after that program finishes. This requires a lot of cleanup and diligence to keep from leaking files... or you can set up a nightly cronjob using find to locate all of the files created more than a week ago and delete them. :) Linux and Unix are a pile of hacks. It isn't going to change anytime soon.

richardwhiuk 5y ago

Parsing the bytestream output of another program is the unix way.

sixothree 5y ago
I get that. I'm just surprised it's still considered acceptable. I feel like even simple JSON would be a better output. Sure, humans would have a problem reading it but that's what shells are for.
- Spivak 5y ago
  That JSON would be the text output of the command. There are utilities like grep, find, sed, awk, git porcelain, readlink, basedir, which, that write output suitable for machines on stdout and other utilities that write output suitable for humans. If you want to be a good UNIX netizen then stdout is for machines while stderr is for humans.

anonydsfsfs 5y ago

I've seen this happen as a workaround for the following bug in Dash: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874264 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874264 If Dash was POSIX compliant, this wouldn't be necessary, but it isn't, so hacky text parsing is sadly necessary.

deleted 5y ago

[deleted]

kayodelycaon 5y ago

> I cannot believe people are parsing text output from other commands in the year 2021 If you're writing shell scripts, there aren't any other options. Here's a lovely little snippet to find the current wifi network for a reMarkable 2. If it's "Aardvark", it runs rsync. :) iw wlan0 info | grep -Po '(?<=ssid ).*' | tr -d '\n' Ugly as hell? Yes, but what's the alternative? Parsing text from a command is a headache, but it works most of the time. There often isn't an API or syscall to get the data you need on a specific system. My favorite ugly hack is having a Ruby on Rails application write a file to disk so it can be processed by another program using a shell and then picking up the output file after that program finishes. This requires a lot of cleanup and diligence to keep from leaking files... or you can set up a nightly cronjob using find to locate all of the files created more than a week ago and delete them. :) Linux and Unix are a pile of hacks. It isn't going to change anytime soon.