3 ms·

This is one area where I wish the Unix philosophy (reuse of tools) was taken a bit further. Too me, every command should be callable as a C library function.

by derekp7 12y ago

This is one area where I wish the Unix philosophy (reuse of tools) was taken a bit further. Too me, every command should be callable as a C library function. That way you wouldn't have to parse the human readable output through a pipe. Not only that, there needs to be both human-readable, as well as machine-readable output to all commands. For example I would love to be able to call "ps" from another script and easily select specific columns from an xml or json output.

sanderjd 12y ago
PowerShell solves this problem by piping around objects instead of strings. It's pretty neat!
laumars 12y ago
Shell scripts can be pretty powerful if you know what you're doing, but I do agree that sometimes the shell script paradigm can be more of a hurdle than a help. However your point about every command being a callable as a C library is kind of possible already. Some commands do have native language libraries (eg libcurl), but you could also fork out to those ELFs if you're feeling really brave (though in all practicality - it's little worse than writing a shell script to begin with). In fact there's times I've been known to cheat with Perl and run (for example): (my $hostname = `hostname`) =~ s/\n//g; because it's quicker and easier to throw together than using the proper Perl libraries (yeah, it's pretty nasty from an academic perspective, but the additional footprint is minimal while the development time saved is significant. Of course, any such code that's used regularly and/or depended on will be cleaned up as and when I have the time. As for your XML or JSON parsing; the same theory as above could be applied: use JSON::Parse 'parse_json'; my $json = `curl --silent http://birthdays.com/myfriends.json`; my $bdays = parse_json($json); print "derekp7's birthday is $bdays{derekp7}"; Obviously these aren't best practices, but if it only running locally (ie this isn't part of a CGI (etc) script that's web accessible) and gets the job done in a hurry then I can't see why I you shouldn't use that for ad hoc reporting.
rmc 12y ago
But one of the unix philosophies is to use plain text. To have everything as a C function means everything needs a new API

by derekp7 12y ago

sanderjd 12y ago

PowerShell solves this problem by piping around objects instead of strings. It's pretty neat!

laumars 12y ago

Shell scripts can be pretty powerful if you know what you're doing, but I do agree that sometimes the shell script paradigm can be more of a hurdle than a help. However your point about every command being a callable as a C library is kind of possible already. Some commands do have native language libraries (eg libcurl), but you could also fork out to those ELFs if you're feeling really brave (though in all practicality - it's little worse than writing a shell script to begin with). In fact there's times I've been known to cheat with Perl and run (for example): (my $hostname = `hostname`) =~ s/\n//g; because it's quicker and easier to throw together than using the proper Perl libraries (yeah, it's pretty nasty from an academic perspective, but the additional footprint is minimal while the development time saved is significant. Of course, any such code that's used regularly and/or depended on will be cleaned up as and when I have the time. As for your XML or JSON parsing; the same theory as above could be applied: use JSON::Parse 'parse_json'; my $json = `curl --silent http://birthdays.com/myfriends.json`; my $bdays = parse_json($json); print "derekp7's birthday is $bdays{derekp7}"; Obviously these aren't best practices, but if it only running locally (ie this isn't part of a CGI (etc) script that's web accessible) and gets the job done in a hurry then I can't see why I you shouldn't use that for ad hoc reporting.

rmc 12y ago

But one of the unix philosophies is to use plain text. To have everything as a C function means everything needs a new API