Re: A Different Shell Philosophy

On 20.12.2005, Jon Forrest <forrest@xxxxxxxxxxxxxxx> wrote:
> Keith Thompson wrote:
>> Jon Forrest <forrest@xxxxxxxxxxxxxxx> writes:
>
>> So it wouldn't have if statements, loops, etc., but it would have (for
>> exapmle) all the stuff that tcsh has but csh doesn't, plus whatever
>> additional features you can think of to make it "user-friendly".
>
> Exactly.
>
>> It's an interesting idea, but often "user-friendly" is
>> "expert-hostile". I often use simple programming constructs on the
>> command line. For example, in tcsh I might type something like this
>> interactively:
>>
>> foreach file (`find . -type f -name '*.in'`) do
>> if (! -e $file:r) then
>> sed 's/FOO/BAR/' $file > $file:r
>> endif
>> end
>>
>> That's probably near the limit of what I'd be willing to do without
>> writing a script (probably in sh or Perl). I'd hate to lose that
>> capability. You might make easy tasks easy and difficult tasks
>> impossible. I'd prefer to make easy tasks easy and difficult tasks
>> possible.
>
> My point is that the kind of thing you mention can be done
> in virtually every scripting language. Why take the time
> and effort to learn yet another scripting language (e.g. the shell
> scripting language) instead of figuring out how to do it
> in your favorite scripting language, the one you already know?

I saw similar argument at Cow build system's site. Uhm, not Cow, Ant
(Java based, hence association). Why learn new makefile syntax for
another build system when you can use well-known XML?

The answer is simple: because it's more convenient. I'm writting a lot
of Perl and a little of Ruby and Tcl scripts, but I wouldn't use any of
them for iterating through all *.jpg files just for single
`convert $FILE ${FILE%.jpg}.png' on each. Shell is a lot better to do
that because I don't need to add whole Perl's bloat over exec nor to use
temporary variable for storing input and output filename.

>> You seem to be assuming that convenient interactive use and powerful
>> scripting are inconsistent goals. Are you sure that's true?
>
> Like I said in another posting, it's clearly possible to ignore
> the scripting capabilities in an existing shell. My comments
> were a reaction to the article I read about a new shell.

I don't think such shell would have much use. It looks like zsh without
programming language to me.

--
Feel free to correct my English
Stanislaw Klekot
.

Relevant Pages

  • Re: A Different Shell Philosophy
    ... The tcsh improved on this. ... The problem is that, despite the name, this group is mostly about the shell ... immediately grant that as a scripting language tcsh sucks - which is why ... But, judged solely on the interactive environment, ...
    (comp.unix.shell)
  • Re: A Different Shell Philosophy
    ... exapmle) all the stuff that tcsh has but csh doesn't, plus whatever additional features you can think of to make it "user-friendly". ... I'd prefer to make easy tasks easy and difficult tasks ... in virtually every scripting language. ... the scripting capabilities in an existing shell. ...
    (comp.unix.shell)
  • Re: [PSH] Methods/functions and blank spaces
    ... to make because PowerShell is both a shell and a scripting language. ... Thus we need to support whitespace as a parameter delimiter. ...
    (microsoft.public.windows.server.scripting)
  • Re: [PSH] Methods/functions and blank spaces
    ... to make because PowerShell is both a shell and a scripting language. ... Thus we need to support whitespace as a parameter delimiter. ...
    (microsoft.public.windows.server.scripting)
  • Re: *attaching* a file to /usr/bin/mail message
    ... > I'm not stuck with mail, I use it with some shell scripts....but yeah, I ... If you're doing scripting, why not use an actual scripting language, and ...
    (freebsd-questions)