Re: [dev] Shell vs C where is the border?
On Mon, Mar 10, 2014 at 09:22:39PM +0100, Paul Onyschuk wrote:
On Mon, 10 Mar 2014 20:39:08 +0100
Szymon Olewniczak szymon.olewnic...@rid.pl wrote:
But having so many individual programs is more harder to use that just
one (we need to run more commands), so reasonable would be to combine
all this commands to one script which would do all this work
automaticaly. So what solution would be better in your opinion? When
we should use shell scripts and when write new C programs to achieve
our goals?
My mail probably will be bounced, but anyway.
It (pipes or lack of them) can be abused either way. Example of way too
many command line flags (GNU ls):
$ ls --help | awk '/^ {2,6}-/{i++} END{print i}'
58
Yeah, you just noticed that the GNU guys always do way too much.
Yet you won't likely use more than a dozen options offered by ls ever
(and fewest on daily basis). Those rare cases, when you need something
specialized could be solved by sed/awk and other filters. Still they
somehow managed to squeeze all those flags there - someone really hates
pipes.
The more I read of POSIX, the more I think those options are only there
because they were easy to add to some specific implementations. Which,
of course, locks the specification ever more to fewer and fewer
implementations, and when you try to do something really crazy and new,
like using a new language (go) or a new paradigm (haskell) then good
luck getting that to conform.
Apart from that, even using C - as was ordained by Saints KR - you have
to jump through some hoops to conform to SUSv3. That's why sbase and
ubase don't even try.
Counter example would be man(1) command (this is personal opinion).
Some implementation are doing something similar to that:
$ zcat some-manpage.1.gz | eqn | grap | pic | tbl | vgrind | refer \
| troff | more
This is running every time when you type man some-manpage. Filter
approach of *roff made sense, when it was used for creating documents
for printing (and it was often most CPU intensive command on the box
according to some accounts).
You forgot the
find $MANPATH -name 'some-manpage.[0-9].*'
But then, this is really necessary, isn't it? I mean, you can use
catpages, which are basically preprocessed manpages, but those aren't
taylored to the terminal you are running it on, and usually they have
page headers and footers that distract when reading.
Apart from that, I have yet to see a better documentation system than
man.
Ciao,
Markus
Re: [dev] Shell vs C where is the border?
Markus Wichmann said: The more I read of POSIX, the more I think those options are only there because they were easy to add to some specific implementations. Actually options in POSIX are mostly those already found in some specific implementations - the main idea behind POSIX is to create a subset of UNIX interfaces one should expect on generic POSIX system. [...] and when you try to do something really crazy and new, like using a new language (go) or a new paradigm (haskell) then good luck getting that to conform. Which is not surprising, given that POSIX is about compatibility, which is almost directly opposite concept to innovation. -- Dmitrij D. Czarkoff
[dev] Shell vs C where is the border?
Hi, I was recetly wondering about the use cases of C and shell. I've seen that this topic appears several times mostly when discussing sbase. Some of you probably knows ffmpeg, software that allows to convert media files between various formats. Imagine now that we have several smaller tools that do one thing and do it well and to convert mkv wideo do webm we do: videostream movie.mkv | theoradec | v8enc video audiostream movie.mkv audio createwebmvideo video audio But having so many individual programs is more harder to use that just one (we need to run more commands), so reasonable would be to combine all this commands to one script which would do all this work automaticaly. So what solution would be better in your opinion? When we should use shell scripts and when write new C programs to achieve our goals? BR, Szymon
Re: [dev] Shell vs C where is the border?
On Mon, Mar 10, 2014 at 12:39 PM, Szymon Olewniczak szymon.olewnic...@rid.pl wrote: So what solution would be better in your opinion? When we should use shell scripts and when write new C programs to achieve our goals? When it makes sense.
Re: [dev] Shell vs C where is the border?
On Mon, 10 Mar 2014 20:39:08 +0100
Szymon Olewniczak szymon.olewnic...@rid.pl wrote:
But having so many individual programs is more harder to use that just
one (we need to run more commands), so reasonable would be to combine
all this commands to one script which would do all this work
automaticaly. So what solution would be better in your opinion? When
we should use shell scripts and when write new C programs to achieve
our goals?
My mail probably will be bounced, but anyway.
It (pipes or lack of them) can be abused either way. Example of way too
many command line flags (GNU ls):
$ ls --help | awk '/^ {2,6}-/{i++} END{print i}'
58
Yet you won't likely use more than a dozen options offered by ls ever
(and fewest on daily basis). Those rare cases, when you need something
specialized could be solved by sed/awk and other filters. Still they
somehow managed to squeeze all those flags there - someone really hates
pipes.
Counter example would be man(1) command (this is personal opinion).
Some implementation are doing something similar to that:
$ zcat some-manpage.1.gz | eqn | grap | pic | tbl | vgrind | refer \
| troff | more
This is running every time when you type man some-manpage. Filter
approach of *roff made sense, when it was used for creating documents
for printing (and it was often most CPU intensive command on the box
according to some accounts).
--
Paul Onyschuk
