Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
comp.unix.shell
+ new post
About this group
Subscribe to this group
This is a Usenet group - learn more
Message from discussion Pattern matching within ,, and ^^ parser
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Janis Papanagnou  
View profile  
 More options Sep 15 2012, 7:24 am
Newsgroups: comp.unix.shell
From: Janis Papanagnou <janis_papanag...@hotmail.com>
Date: Sat, 15 Sep 2012 13:24:35 +0200
Local: Sat, Sep 15 2012 7:24 am
Subject: Re: Pattern matching within ,, and ^^ parser
Print | View thread | Show original | Report this message | Find messages by this author
On 15.09.2012 07:39, Martin Vaeth wrote:

> Janis Papanagnou <janis_papanag...@hotmail.com> wrote:
>> On 13.09.2012 10:14, Martin Vaeth wrote:
>>> Janis Papanagnou <janis_papanag...@hotmail.com> wrote:

>>>>> There are several other problems with awk than only the speed:

>>>>> 1. It is not that standardized; probably there are also versions with
>>>>>    various kind of bugs in the wild.

>>>> In both of those respects we have more issues with shells than with awk.

>>> For shells, almost all current systems follow POSIX.

>> The prominent ones do. Nonetheless even some basic constructs aren't
>> standardised, which result in different behaviour; most prominent
>> example the "pipe processes executed in subprocess" discrepancy.
>> And also you would have to limit yourself to the small POSIX subset,

> So what? If you use incompatible expansions of a particular shell,

The "pipe processes executed in subprocess" issue is not standardized
(probably because shells do behave differently; but anyway); it's bad
to have different behaviour and to need to work around that with ugly
constructs to make that work reliable across POSIX shells.

(WRT the limitations by POSIX subset see below.)

> this runs in gernal only on the particular shell. Otherwise it is
> standardized. So in which sense does that support your sentence
> "In both of those respects we have more issues with shells
> than with awk."?

It's the amount of available extensions in shells compared to awk, and
it's the amount of necessary extensions in shells compared to awk.

I think I've explained that already with other words; you can write
most of your programs in a well maintainable way in awk, and you don't
need to use any of the few extensions to do so. To make shell programs
readable by abstaining from non-POSIX extensions is hardly possible in
that way; consider (for example) the ${ // / } or ${ : : } constructs,
just to name some that are available in the prominent shells but not
in the standard.

>> not to mention to implement functionality that you
>> just cannot implement with POSIX shell.

> For bash such a functionality remains yet to be found
> (only candidate I know is <(...), but there are FIFOs).

The <(...) construct is also depending on support by the underlying OS.
But if supported by the OS it's at least available by all the prominent
shells.

> For zsh there are a few like assignment to USER.
> Again: So what?  If you really need zsh features, program in zsh...

Yes. And leaving the standard path.

>> Don't recall such older awk's limitations, and I've never stumbled
>> across them.

> See e.g. Section 11.9 in
> http://oreilly.com/catalog/unixnut3/chapter/ch11.html

Those, AFAICT, are limits you have depending on OS-restrictions, limits
that you find also in shells, and limits typical for non-contemporary
ancient systems. Anything more specific so that we can judge?

> Some practical limits of particular awk implementations are
> mentioned here:
> http://computer-programming-forum.com/11-awk/88037ec462264097.htm

The quoted thread seems to be Windows/DOS oriented. It's beyond me which
limits that environment will impose on the applications.

It would be helpful if you could quote a reference of any actual limits,
so that we can see if any is an OS issue (WinDOS), a historic awk limit,
an academic limit, or actually one that is relevant for awk's of the
last - since you like the comparison with perl - 20/25 years (or so).

> Just because your gawk implementation perhaps doesn't have it,
> it does not mean that your program works reliable on every machine.

Here I agree with you.

> OTOH, with perl you do not have to fear such a thing.

Don't compare apples with bananas. Or is there a POSIX or ANSI standard
for perl, as opposed to POSIX shell and POSIX awk?

Janis

> [...]


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2013 Google