dtksh ${$} in heredoc bug?

dtksh ${$} in heredoc bug?

Post by Sweth Chandramou » Wed, 09 Feb 2000 04:00:00



        on a machine running solaris 7, i experience the
following strangeness:

~: /usr/dt/bin/dtksh
$
$ echo $$
7910
$ echo ${$}
7910
$ cat <<EOF

Quote:> $$
> EOF

7910
$ cat <<EOF
Quote:> ${$}
> EOF

dtksh: syntax error: `$' unexpected
$ exit
~: /bin/ksh
$
$ echo $$
7917
$ echo ${$}
7917
$ cat <<EOF
Quote:> $$
> EOF

7917
$ cat <<EOF
Quote:> ${$}
> EOF

7917
$ exit

        .  /bin/ksh on solaris is ksh88, while dtksh is ksh93;
is this behaviour due to a difference between ksh versions, or is it
a bug in dtksh?

        -- sweth.

--

<a href="http://astaroth.nit.gwu.edu/resume/">Will Work For Food.</a>
<a href="http://astaroth.nit.gwu.edu/~sweth/disc.html">*</a>

 
 
 

dtksh ${$} in heredoc bug?

Post by brian hile » Thu, 10 Feb 2000 04:00:00



>    on a machine running solaris 7, i experience the
> following strangeness:
> ~: /usr/dt/bin/dtksh
> $
> $ echo $$
> 7910
> $ echo ${$}
> 7910
> $ cat <<EOF
>> $$
>> EOF
> 7910
> $ cat <<EOF
>> ${$}
>> EOF
> dtksh: syntax error: `$' unexpected
> $ exit
> ~: /bin/ksh
> $
> $ echo $$
> 7917
> $ echo ${$}
> 7917
> $ cat <<EOF
>> $$
>> EOF
> 7917
> $ cat <<EOF
>> ${$}
>> EOF
> 7917
> $ exit
>    .  /bin/ksh on solaris is ksh88, while dtksh is ksh93;
> is this behaviour due to a difference between ksh versions, or is it
> a bug in dtksh?
>    -- sweth.

It's a bug. Dtksh is not _precisely_ ksh93 -- it's technically
ksh93a that has had minor (and unspecified) source code revisions
on a different versioning branch from other distribution ksh93s.
This information come to me from AT&T programmers working with
ksh93 and I have no additional information.

It is my general observation that the ksh93 shell and documentation
was rushed into distribution, and has more bugs and oversights than
should be the case, especially in the earlier versions.

Generally speaking, there is rarely any intention necessity of
variable substitution being applied to the contents of a here-file.
Turn off such processing, if not desired, by using the syntax "cat
<<-EOF" (note the minus); it is minimally more efficient as well.

-Brian

 
 
 

dtksh ${$} in heredoc bug?

Post by Sweth Chandramou » Thu, 10 Feb 2000 04:00:00




Quote:>>        .  /bin/ksh on solaris is ksh88, while dtksh is ksh93;
>> is this behaviour due to a difference between ksh versions, or is it
>> a bug in dtksh?
>>        -- sweth.

>It's a bug. Dtksh is not _precisely_ ksh93 -- it's technically
>ksh93a that has had minor (and unspecified) source code revisions
>on a different versioning branch from other distribution ksh93s.

        good to know.

[snip]

Quote:>It is my general observation that the ksh93 shell and documentation
>was rushed into distribution, and has more bugs and oversights than
>should be the case, especially in the earlier versions.

        i've only been using ksh93 for the last six months or
so, but i haven't seen any other issues with it.  what other "bugs and
oversights" have you seen?

Quote:>Generally speaking, there is rarely any intention necessity of
>variable substitution being applied to the contents of a here-file.
>Turn off such processing, if not desired, by using the syntax "cat
><<-EOF" (note the minus); it is minimally more efficient as well.

        i actually use parameter expansion within heredocs all
the time; it's great for putting wrappers around certain interactive
applications (e.g. oracle's sqlplus).  and in the example i gave,
where the entire heredoc was a single parameter expansion, disabling
expansion would have been kind of pointless.  :)

        -- sweth.

--

<a href="http://astaroth.nit.gwu.edu/resume/">Will Work For Food.</a>
<a href="http://astaroth.nit.gwu.edu/~sweth/disc.html">*</a>

 
 
 

dtksh ${$} in heredoc bug?

Post by brian hile » Fri, 11 Feb 2000 04:00:00





> > ...
> the time; it's great for putting wrappers around certain interactive
> applications (e.g. oracle's sqlplus).  and in the example i gave,
> where the entire heredoc was a single parameter expansion, disabling
> expansion would have been kind of pointless.  :)

Okay. I just wanted to know that you were aware of the potential
reducndancy if you indeed were not using this feature of variable
expansion within here-docs, making the bug moot.

-Brian

 
 
 

dtksh ${$} in heredoc bug?

Post by Dan Merc » Fri, 11 Feb 2000 04:00:00






> [snip]
>>It is my general observation that the ksh93 shell and documentation
>>was rushed into distribution, and has more bugs and oversights than
>>should be the case, especially in the earlier versions.
>    i've only been using ksh93 for the last six months or
> so, but i haven't seen any other issues with it.  what other "bugs and
> oversights" have you seen?

>    -- sweth.

I found a cute one in dtksh.  The following line would cause a seg
fault:

LOCALHOST=( [limstd]=1 [limswks7]=1 [ltdata]=1 [ramsey]=1 [zpike]=1 )

When debugging it with -x,  it wouldn't core!  So I put in print
statements to gather info - wouldn't core.  Finally,  I added a nop
after the above statement - no more cores! Go figure!

--
Dan Mercer

Opinions expressed herein are my own and may not represent those of my employer.

 
 
 

dtksh ${$} in heredoc bug?

Post by Sweth Chandramou » Fri, 11 Feb 2000 04:00:00



>I found a cute one in dtksh.  The following line would cause a seg
>fault:

>LOCALHOST=( [limstd]=1 [limswks7]=1 [ltdata]=1 [ramsey]=1 [zpike]=1 )

>When debugging it with -x,  it wouldn't core!  So I put in print
>statements to gather info - wouldn't core.  Finally,  I added a nop
>after the above statement - no more cores! Go figure!

        was that line the entirety of the script?  i can't get
a script containing that line to core at all.

        -- sweth.

--

<a href="http://astaroth.nit.gwu.edu/resume/">Will Work For Food.</a>
<a href="http://astaroth.nit.gwu.edu/~sweth/disc.html">*</a>

 
 
 

dtksh ${$} in heredoc bug?

Post by Dan Merc » Sat, 12 Feb 2000 04:00:00





>>I found a cute one in dtksh.  The following line would cause a seg
>>fault:

>>LOCALHOST=( [limstd]=1 [limswks7]=1 [ltdata]=1 [ramsey]=1 [zpike]=1 )

>>When debugging it with -x,  it wouldn't core!  So I put in print
>>statements to gather info - wouldn't core.  Finally,  I added a nop
>>after the above statement - no more cores! Go figure!
>    was that line the entirety of the script?  i can't get
> a script containing that line to core at all.

>    -- sweth.

No,  it's a very long script that posts a toolbar holding two buttons,
two labels and two DtComboBoxes.  Like I say,  it was very bizarre
and seemed to have more to do with the sequence of when the command
occurred than the command itself.  I tried reproducing it in a standalone
situation,  but was unsuccessful.

--
Dan Mercer

Opinions expressed herein are my own and may not represent those of my employer.

 
 
 

dtksh ${$} in heredoc bug?

Post by brian hile » Sat, 12 Feb 2000 04:00:00





>> [snip]
>>        i've only been using ksh93 for the last six months or
>> so, but i haven't seen any other issues with it.  what other "bugs and
>> oversights" have you seen?
> LOCALHOST=( [limstd]=1 [limswks7]=1 [ltdata]=1 [ramsey]=1 [zpike]=1 )

I have annotated my copy of "The New Kornshell Command and Programming
Language" with hundreds of bugs, comments, reminders to check,
pointers to misfeatures, inconsistencies of documentation, paucity
of documentation, lacking documentation, ... and so on and so on
and so on. The book (and the language) is just _crammed_ with them.

You would not believe all the features of ksh93 which are only
explicable through a careful strings(1) search.

I _still_ have not managed to devine when ksh93 will use its "special
shell builtin versions" of common Unix executables; ksh93 has seen
fit to omit this information in the output of a "whence" command.

After this tease, I suppose you, as a sophisticated scripter who
I know to be interested in implementation and debugging details,
will want to persue them. And I have no problem at all with letting
you see them, but as I have intimated above, the fact is that (1)
the errata is not in machine reabable format, (2) the bugs, etc, are
in large part the exegesis of a "language lawyer" (i.e. to no one's
interest except the designer,) and (3) the stuff that _is_ on my SS1+
at home is regretable (as I seem to sheepishly have to admit more and
more often to email requests,) unobtainable of late.

Keep going with your excellent Web Site,  Dan Mercer. Will you be
posting your dtksh examples? (Not that I can run them!) Just out
of curiousity, have you used J. Korn's "deet" de* written in
tksh?

http://www.veryComputer.com/~jlk/deet/

-Brian

-Brian

 
 
 

dtksh ${$} in heredoc bug?

Post by Sweth Chandramou » Sun, 13 Feb 2000 04:00:00







>>> [snip]
>>>    i've only been using ksh93 for the last six months or
>>> so, but i haven't seen any other issues with it.  what other "bugs and
>>> oversights" have you seen?
>> LOCALHOST=( [limstd]=1 [limswks7]=1 [ltdata]=1 [ramsey]=1 [zpike]=1 )

>I have annotated my copy of "The New Kornshell Command and Programming
>Language" with hundreds of bugs, comments, reminders to check,
>pointers to misfeatures, inconsistencies of documentation, paucity
>of documentation, lacking documentation, ... and so on and so on
>and so on. The book (and the language) is just _crammed_ with them.

>You would not believe all the features of ksh93 which are only
>explicable through a careful strings(1) search.

        i've seen lots of confusion in the docs, but very
little in the actual implementation that can't be explained after some
careful reasoning and a little educated guesswork.

Quote:>I _still_ have not managed to devine when ksh93 will use its "special
>shell builtin versions" of common Unix executables; ksh93 has seen
>fit to omit this information in the output of a "whence" command.

        the only "special built-in" commands i know of in
ksh are the ones marked as such in the the manpage, and none of those are
duplicates of external executables.  assuming there were special builtins
that duplicate executables, why wouldn't they be used just as any other
builtin (before executables unless either an explicit path to an
executable is set or the command builtin is used)?

[snip]

Quote:>(2) the bugs, etc, are
>in large part the exegesis of a "language lawyer" (i.e. to no one's
>interest except the designer,)

        or other language lawyers.  :)  even so, i've found
that figuring out how behaviour differs from description is one of the
best ways to really understand a system.

        -- sweth.

--

<a href="http://astaroth.nit.gwu.edu/resume/">Will Work For Food.</a>
<a href="http://astaroth.nit.gwu.edu/~sweth/disc.html">*</a>

 
 
 

dtksh ${$} in heredoc bug?

Post by Dan Merc » Tue, 15 Feb 2000 04:00:00









>>>> [snip]
>>>>        i've only been using ksh93 for the last six months or
>>>> so, but i haven't seen any other issues with it.  what other "bugs and
>>>> oversights" have you seen?
>>> LOCALHOST=( [limstd]=1 [limswks7]=1 [ltdata]=1 [ramsey]=1 [zpike]=1 )

>>I have annotated my copy of "The New Kornshell Command and Programming
>>Language" with hundreds of bugs, comments, reminders to check,
>>pointers to misfeatures, inconsistencies of documentation, paucity
>>of documentation, lacking documentation, ... and so on and so on
>>and so on. The book (and the language) is just _crammed_ with them.

>>You would not believe all the features of ksh93 which are only
>>explicable through a careful strings(1) search.
>    i've seen lots of confusion in the docs, but very
> little in the actual implementation that can't be explained after some
> careful reasoning and a little educated guesswork.

>>I _still_ have not managed to devine when ksh93 will use its "special
>>shell builtin versions" of common Unix executables; ksh93 has seen
>>fit to omit this information in the output of a "whence" command.
>    the only "special built-in" commands i know of in
> ksh are the ones marked as such in the the manpage, and none of those are
> duplicates of external executables.  assuming there were special builtins
> that duplicate executables, why wouldn't they be used just as any other
> builtin (before executables unless either an explicit path to an
> executable is set or the command builtin is used)?

You seem to be confusing ksh88 with ksh93.  It has as builtins the following
duplicates of external executables:

$ builtin|grep /
/bin/basename
/bin/cat
/bin/chmod
/bin/cmp
/usr/bin/cut
/bin/dirname
/bin/head
/usr/bin/logname
/bin/mkdir
/bin/uname
/bin/wc

From my experimentation ksh93 used the builtin only when invoked
by basename - when I invoke /usr/bin/cut I got /usr/bin/cut which is
certainly NOT what I expected.

--
Dan Mercer

Quote:

> [snip]
>>(2) the bugs, etc, are
>>in large part the exegesis of a "language lawyer" (i.e. to no one's
>>interest except the designer,)
>    or other language lawyers.  :)  even so, i've found
> that figuring out how behaviour differs from description is one of the
> best ways to really understand a system.

>    -- sweth.

Opinions expressed herein are my own and may not represent those of my employer.
 
 
 

dtksh ${$} in heredoc bug?

Post by Sweth Chandramou » Tue, 15 Feb 2000 04:00:00



>You seem to be confusing ksh88 with ksh93.  

        indeed, i was.  my apologies.  the confusion with ksh93
builtins comes, i think, from the fact that the "builtin" command, presumably
in an attempt to indicate that a given builtin is actually a duplicate of an
external app, lists some builtins as "/bin/cut", or whatever.  as far as the
parsing of the command line goes, however, the builtin is still simply "cut";
if "cut" is specified on the command line, without any path, then, since
builtins are checked for before executables, the builtin will be used; if a
path is specified, however, then the builtin check will not find a match,
so the external app will be used.  whence -v will show you what is going on:

$ whence -v cut
cut is a shell builtin version of /bin/cut
$ whence -v /bin/cut
/bin/cut is a tracked alias for /bin/cut

        -- sweth.

--

<a href="http://astaroth.nit.gwu.edu/resume/">Will Work For Food.</a>
<a href="http://astaroth.nit.gwu.edu/~sweth/disc.html">*</a>

 
 
 

1. Read bug in ksh93 (dtksh)

The following code works as expected in ksh88:

$ echo "pat\c" | read pat;echo "pat='$pat'"
pat='pat'

in ksh93:

$ ksh93
$ echo "pat\c" | read pat;echo "pat='$pat'"
pat='pa'
$ exit;dtksh
$ echo "pat\c" | read pat;echo "pat='$pat'"
pat='pa'

I discovered this quite by accident while adding functionality to
nedit.  I wrote a nedit macro that selects the current word
and filters it to a dtksh script.  The filtering process cats the file
without a newline.  The dtksh reads the pattern,  then uses it to
grep a database of Applix macro names and completes the macro.  If
more than 1 name is found,  a Selection Box dialog is posted so you
can select the correct function.  I used:

read pat

to get the pattern,  but it kept coming back 1 char short.  I had to
change that to:

pat="$(cat)"

Opinions expressed herein are my own and may not represent those of my employer.

2. freebsd & mysql ...?

3. Line monitor software

4. How to use heredoc in makefile

5. dynamic linking problems

6. advanced heredoc usage

7. Netscape memory problem

8. Registering new widgets in AIX dtksh

9. Simple dtksh Questions

10. /usr/dt/bin/dtksh and /usr/bin/ksh

11. Attaching C code to dtksh

12. dtksh...?