bash conversion trouble.

bash conversion trouble.

[Ray Andrews]

Gentlemen:


I'm trying to convert a long script from bash, which I know not at all, 
to zsh, which I know hardly better:

bash likes thisbut zsh throws a syntax error:

     case "${USE_OVERLAYFS,,}" in

zsh likes this:

     case "${USE_OVERLAYFS}" in

and I can't see what the pair of commas would do anyway and I'm afraid 
to ask.  Will they be missed?

Re: bash conversion trouble.

[Bart Schaefer]

On Feb 24,  5:35pm, Ray Andrews wrote:
} Subject: bash conversion trouble.
}
} Gentlemen:
} 
} 
} I'm trying to convert a long script from bash, which I know not at all, 
} to zsh, which I know hardly better:
} 
} bash likes thisbut zsh throws a syntax error:
} 
}      case "${USE_OVERLAYFS,,}" in

       ${parameter^pattern}
       ${parameter^^pattern}
       ${parameter,pattern}
       ${parameter,,pattern}
              Case modification. This expansion modifies the case
              of alphabetic characters in parameter. The pattern
              is expanded to produce a pattern just as in pathname
              expansion. The ^ operator converts lowercase letters
              matching pattern to uppercase; the , operator converts
              matching uppercase letters to lowercase. The ^^ and ,,
              expansions convert each matched character in the expanded
              value; the ^ and , expansions match and convert only
              the first character in the expanded value. If pattern
              is omitted, it is treated like a ?, which matches every
              character. If parameter is @ or *, the case mod ification
              operation is applied to each positional parameter in turn,
              and the expansion is the resultant list. If parameter
              is an array variable sub scripted with @ or *, the case
              modification operation is applied to each member of the
              array in turn, and the expansion is the resultant list.

So bash ${name,,} is zsh ${(L)name} ... and there isn't a simple zsh
equivalent for what happens if there is a pattern following the ,,

It'd also be kind of ugly to add ${name^pat} to zsh at this point, as
we've already got ${name:^var} and ${name:^^var} which mean something
radically different.  (Not implementation-ugly, but semantics-ugly.)

Re: bash conversion trouble.

[Ray Andrews]

On 24/02/17 08:41 PM, Bart Schaefer wrote:
> So bash ${name,,} is zsh ${(L)name} ... and there isn't a simple zsh
> equivalent for what happens if there is a pattern following the ,,
Even more cryptic than our way, which at least is sorta obviously a 
modifier and can obviously be one of a family of modifiers which will 
all share the same form.  So we win.  BTW, in 700 lines of bash, so far 
that's been the only outright breakage except that it seems that zsh 
arrays are one based and bash are zero, which almost kills my little 
effort since there are dozens of them.

Re: bash conversion trouble.

[Peter Stephenson]

On 25 February 2017 15:13:20 GMT+00:00, Ray Andrews <rayandrews@eastlink.ca> wrote:
> BTW, in 700 lines of bash, so far
>
>that's been the only outright breakage except that it seems that zsh 
>arrays are one based and bash are zero, which almost kills my little 
>effort since there are dozens of them.

setopt ksharrays

simulates this, but obviously if you want consistency with other
functions, don't even think sbout it.

pws

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: bash conversion trouble.

[Bart Schaefer]

On Feb 25,  3:26pm, Peter Stephenson wrote:
}
} setopt ksharrays
} 
} simulates this, but obviously if you want consistency with other
} functions, don't even think sbout it.

Also typically do

    setopt localoptions ksharrays

so the zero-based-ness doesn't leak out to the rest of the shell.  If
you're in a standalone script you won't be sourcing, that's not needed.

Re: bash conversion trouble.

[Ray Andrews]

On 25/02/17 07:55 AM, Bart Schaefer wrote:
> On Feb 25,  3:26pm, Peter Stephenson wrote:
> }
> } setopt ksharrays
> }
> } simulates this, but obviously if you want consistency with other
> } functions, don't even think sbout it.
>
> Also typically do
>
>      setopt localoptions ksharrays
>
> so the zero-based-ness doesn't leak out to the rest of the shell.  If
> you're in a standalone script you won't be sourcing, that's not needed.
>
Just curious: why would that have been changed?  It's the sort of thing 
that would obviously make trouble, and of course if there's a good 
reason for it, that's too bad, but what's the good reason?  These zero 
or one based counting issues are everywhere and I've never been able to 
see why one is to be preferred over the other, tho zero might seem more 
computery and one would be more 'natural' I suppose.

Re: bash conversion trouble.

[Bart Schaefer]

On Feb 25,  8:24am, Ray Andrews wrote:
}
} Just curious: why would that have been changed?

This comes from zsh's original heritage as a bourne-shell-like shell
intended for students who were trained on BSD csh.  Also this happened
before ksh was widely available outside an AT&T research lab so there
was no bourne-shell array syntax to "change".

Exactly why csh adopted 1-based arrays is probably lost to history at
this point, but I suspect the argument goes something like this.

When invoking a script e.g. "prog this is a test", internally $0 is
"prog" and the arguments are $1 = this, $2 = is, etc.  Therefore when
referring to the positional paramters, counting always starts from 1.
Consequently it "makes sense" to have other arrays also count from 1,
so that e.g.

    newarray=("$@")
    if [ "$newarray[1]" = "$1" ]; then echo copied correctly; fi

It's strange to have to adjust thinking to zero-based for other arrays
when the most obvious default array seems to start at 1.

Re: bash conversion trouble.

[Ray Andrews]

On 25/02/17 09:02 AM, Bart Schaefer wrote:
> On Feb 25,  8:24am, Ray Andrews wrote:
> }
> } Just curious: why would that have been changed?
>
> This comes from zsh's original heritage as a bourne-shell-like shell
> intended for students who were trained on BSD csh.  Also this happened
> before ksh was widely available outside an AT&T research lab so there
> was no bourne-shell array syntax to "change".
>
> Exactly why csh adopted 1-based arrays is probably lost to history at
> this point, but I suspect the argument goes something like this.
>
> When invoking a script e.g. "prog this is a test", internally $0 is
> "prog" and the arguments are $1 = this, $2 = is, etc.  Therefore when
> referring to the positional paramters, counting always starts from 1.
> Consequently it "makes sense" to have other arrays also count from 1,
> so that e.g.
>
>      newarray=("$@")
>      if [ "$newarray[1]" = "$1" ]; then echo copied correctly; fi
>
> It's strange to have to adjust thinking to zero-based for other arrays
> when the most obvious default array seems to start at 1.
>
Interesting.  So bash and ksh went one way an zsh and csh went the 
other.  Obviously the decision was made in the context of the time, but 
I'd have expected zsh to go with bash.  One hears nothing but bad things 
about csh.  But it's good to stop looking for some deep logic to it and 
just realize that it's arbitrary. The only real irritation is that it 
isn't consistent.  Yeah, why not just use natural counting?   That 
array[9] is the tenth element has always seemed a bit dumb but I'm used 
to it from C.

Re: bash conversion trouble.

[Bart Schaefer]

On Feb 25, 11:13am, Ray Andrews wrote:
}
} Interesting.  So bash and ksh went one way an zsh and csh went the 
} other.  Obviously the decision was made in the context of the time, but 
} I'd have expected zsh to go with bash.

The point is that zsh "went" before there were arrays in bash to follow.
"I'd have expected gorillas to be the same color as orangutans."

} One hears nothing but bad things about csh.

Yes, the intent of zsh was to take only the good things from csh and for
everything else be like the Bourne shell (which is NOT "like bash", nor
is it even "like POSIX" which came even later).

Various extensions for bash/ksh compatibility were then added to make
it simpler to do exactly the kind of script conversion you're currently
working on, and to help people migrating from bash et al. in the same
way that the original design was meant to assist people migrating from
csh.

} Yeah, why not just use natural counting?   That array[9] is the tenth
} element has always seemed a bit dumb but I'm used to it from C.

In C it makes sense because arrays are based on pointer arithmetic so
array[0] == *(array+0) == the start of the array.  Shells don't have
such pointer arithmetic, at least not exposed by default.  That's even
the reason that $0 == the program name, because in the underlying C
the 0 element of the array passed to execve() is the program name.

Re: bash conversion trouble.

[Ray Andrews]

On 25/02/17 12:09 PM, Bart Schaefer wrote:
> The point is that zsh "went" before there were arrays in bash to follow.
> "I'd have expected gorillas to be the same color as orangutans."
Yes, that much I know, if I stop to recall it.
> } One hears nothing but bad things about csh.
>
> Yes, the intent of zsh was to take only the good things from csh and for
> everything else be like the Bourne shell (which is NOT "like bash", nor
> is it even "like POSIX" which came even later).
Sure, but I've always presumed that bash is 'like' sh, for obvious 
reasons so the likeness would come from the parent.  Why was there zsh 
and bash anyway?  It seems to me that the goals would have been so 
similar that two projects were a duplication of effort.
>
> In C it makes sense because arrays are based on pointer arithmetic so
> array[0] == *(array+0) == the start of the array.  Shells don't have
> such pointer arithmetic, at least not exposed by default.  That's even
> the reason that $0 == the program name, because in the underlying C
> the 0 element of the array passed to execve() is the program name.
>
Yeah, thanks for reminding me.  zero base really is the more rigorously 
correct.

Re: bash conversion trouble.

[Bart Schaefer]

On Feb 25,  9:05pm, Ray Andrews wrote:
}
} Sure, but I've always presumed that bash is 'like' sh, for obvious 
} reasons so the likeness would come from the parent.  Why was there zsh 
} and bash anyway?  It seems to me that the goals would have been so 
} similar that two projects were a duplication of effort.

There was no zsh "project"; it was developed by a single student (Paul
Falstad) at Princeton for use by himself and other students on the
time-sharing system there.  There weren't outside contributors until a
few years later after the sources appeared on the comp.sources.unix
newsgroup.

The goals were not at all similar.  Bash was an effort to re-create the
Bourne shell under the GPL; zsh was an effort to introduce structured
shell language and scripting to csh users.

Re: bash conversion trouble.

[Ray Andrews]

On 26/02/17 09:19 AM, Bart Schaefer wrote:
> The goals were not at all similar.  Bash was an effort to re-create the
> Bourne shell under the GPL; zsh was an effort to introduce structured
> shell language and scripting to csh users.
Most interesting.  An insight like that will explain much.  I presumed 
bash to be no more than the natural evolution of sh and zsh to be more 
or less the same, with no particular nod to csh.  I know that ksh was a 
truly separate project.  Is there a brief history of shells that one 
might read?  Anyway, I always took differences between zsh and bash to 
be 'deliberate' if that's the right word -- gorillas making a very 
definite point of not being orange.  Thus my original question and now I 
see what you were getting at as far as gorillas.

Shell history (Re: bash conversion trouble.)

[Bart Schaefer]

On Feb 26, 10:03am, Ray Andrews wrote:
}
} Is there a brief history of shells that one might read?

This:

http://www.softpanorama.org/People/Shell_giants/introduction.shtml

has the timeline mostly correct; but the author is so far off on the
relative merits of the Bourne and C shell scripting languages, for
example, as to make most of his editorializing ignorable.  He seems
to have some kind of axe to grind with Steve Bourne and wastes a lot
of words bashing him (no pun intended), but there is a lot of useful
source material quoted or linked.

(As an example, the Bourne language can be sensibly pre-parsed into an
execution tree -- the basis for zsh's eventual adoption of wordcode for
internal representation -- whereas the csh language makes no sense if
it is not executed in parallel with parsing.  I've even written self-
modifying csh programs that take advantage of this by overwriting the
tail of their own input file in the middle of a loop.)

This:

http://www.ibm.com/developerworks/library/l-linux-shells/

has a chart showing the timeline in detail, though to put zsh on a
direct line from csh is also misleading; it was written from scratch
and should probably have dotted lines from all of csh, ksh, and rc
as ideas were borrowed from all of those (the ksh ideas having been
taken from a [sometimes mis-] reading of the ksh manual pages, as
ksh implementations were still proprietary at that time).

Several of the O'Reilly Media books on shell programming also contain
chapters on shell history, which are accurate to varying degrees though
more correct than not.

Re: Shell history (Re: bash conversion trouble.)

[Ray Andrews]

On 26/02/17 01:10 PM, Bart Schaefer wrote:
> On Feb 26, 10:03am, Ray Andrews wrote:
> }
> } Is there a brief history of shells that one might read?
>
> This:
>
> http://www.softpanorama.org/People/Shell_giants/introduction.shtml
>
> has the timeline mostly correct; but the author is so far off on the
> relative merits of the Bourne and C shell scripting languages, for
> example, as to make most of his editorializing ignorable.  He seems
> to have some kind of axe to grind with Steve Bourne and wastes a lot
> of words bashing him (no pun intended), but there is a lot of useful
> source material quoted or linked.

I almost stopped reading when he started to foam at the mouth, it ruins 
the document.  Anyway thanks, that's as much of a brief history as I 
need.  One thing tho:

"no clean separation between lexical analysis and syntax analysis"

I sure can agree with that, it seems to be at the heart of many 
difficulties.

Re: bash conversion trouble.

[Stephane Chazelas]

2017-02-25 09:02:18 -0800, Bart Schaefer:
> On Feb 25,  8:24am, Ray Andrews wrote:
> }
> } Just curious: why would that have been changed?
> 
> This comes from zsh's original heritage as a bourne-shell-like shell
> intended for students who were trained on BSD csh.  Also this happened
> before ksh was widely available outside an AT&T research lab so there
> was no bourne-shell array syntax to "change".
> 
> Exactly why csh adopted 1-based arrays is probably lost to history at
> this point, but I suspect the argument goes something like this.
[...]

See also
https://unix.stackexchange.com/questions/252368/is-there-a-reason-why-the-first-element-of-a-zsh-array-is-indexed-by-1-instead-o/252405#252405

pasted below for convenience:


- Virtually all shell arrays (Bourne, csh, tcsh, fish, rc, es,
  yash) start at 1. ksh is the only exception that I know (bash
  just copied ksh).
- Most interpreted languages at the time (early 90s): awk, tcl
  at least, and tools typically used from the shell (cut -f1-3,
  head -n 3, sort -k1,3, cal 1 2015, comm -1) start at 1. sed,
  ed, vi number their lines from 1...
- zsh takes the best of the Bourne shell and csh. The Bourne
  shell array $@ start at 1. zsh is consistent with its handling
  of $@ (like in Bourne) or $argv (like in csh). See how
  confusing it is in ksh where ${@:0:1} does not give you the
  first positional parameter for instance.
- A shell is a user tool before being a programming language. It
  makes sense for most users to have the first element in $a[1].
  It also means that the number of elements is the same as the
  last indice (in zsh like in most other shells except ksh,
  arrays are not sparse).
- a[1] for the first element is consistent with a[-1] for the
  last.

So IMO the question should rather be: what got into David Korn's
head to make its arrays start at 0?

Re: bash conversion trouble.

[Ray Andrews]

On 28/02/17 07:56 AM, Stephane Chazelas wrote:
>
> So IMO the question should rather be: what got into David Korn's
> head to make its arrays start at 0?
>
Thanks,  so ksh and bash are the exceptions, but bash, being so 
ubiquitous, is now the de facto standard.  As you say, there is the 
issue of convenience vs. (perhaps) the C-ish strictness of starting at 
zero, which is where computers start counting from.  BTW I notice you 
are one of the stalwarts on stackexchange, that's appreciated. I love 
all this history stuff, it adds a certain color to the thing.  Even dumb 
things are more endurable when you know how it got that way.
>