Bug in ksh 88[df] "print -u2" and/or "read" statement.

Bug in ksh 88[df] "print -u2" and/or "read" statement.

Post by Marnix van Amme » Wed, 31 Jul 1991 05:21:25



I described this bug in a previous posting in comp.unix.shell
over a month ago, but have only received one response, an email
which confirmed the bug in SCO unix 3.2.2 ksh and in Aspen's ksh
(although the errors showed up slightly different).  I have since
also found the bug in the ksh in the AT&T 7300 (UNIX PC).  I have
have seen this same bug in ksh 88d, 88e, and 88f, so it probably
goes back aways.

I'm reposting this bug, this time cross posted to comp.unix.questions
and comp.unix.wizards.  For comp.unix.questions my question is "is this
a known bug?"  For comp.unix.wizards I just hope some wizard will find
and identify the bug.

Mr. Korn, are you out there?

Reposting of article (originally posted on Jun 19th 1991):
------------------------------------------------------------------------
This problem may exist in ksh version E as well, but for sure it's
in ksh versions D and F.  The trouble is that the ksh will replace a
character with the return character '\015' in the middle of some
text I'm trying to send to standard error output.  The following
script illustrates the problem:

################################# Start of script ###########################
print -u2  "I need to ask you a few questions."
print -u2  "Have you already filtered the data into a file (y/n) ? \c"
read       Answer
print -u2  "Before proceding, please enter file type [hex/octal/binary]: \c"
read       FileType
################################# End of script #############################

The last print statement has the 'l' in "please" changed to a return
character so that the resulting screen looks something like:
-------------------------------------------------------
I need to ask you a few questions.
Have you already filtered the data into a file (y/n) ?
ease enter file type [hex/octal/binary]:
-------------------------------------------------------

I have duplicated this on a 3B4000 and on a 3B15 running SYSV,
release 3.  I have the same trouble even with my "ENV" variable
unset and starting up a fresh ksh.

With trial and error I have found that the trouble is affected by
the COLUMN variable.  I have the problem with no COLUMN variable set
or with COLUMN set to 80 or less.  Ksh's behavior is similar to what
happens when you are on the command line editing a line longer than
COLUMNS characters and you get to the right edge of the screen (in
vi mode anyway).  You have to be "print"ing with "-u2" and you have
to do read's for this bug to show.  If you put almost any command
prior to the last read, the trouble will clear.  Simple deleting the
last read will also get rid of the trouble.

Is this a known bug?  Can other's duplicate this as well?

Thanks for any information.

Marnix A. van Ammers
Pacific Bell ESAC
415-645-5196
------------------------------------------------------------------------

 
 
 

Bug in ksh 88[df] "print -u2" and/or "read" statement.

Post by lawrence.v.cipria » Wed, 31 Jul 1991 23:39:38



Quote:>Mr. Korn, are you out there?

I emailed the bug report to him; I'll post his response if any.  I was
able to reproduce it on an AT&T 6386/25 WGS running ksh88f.
--

"Fight fire with fire, I always say." -- Bugs Bunny

 
 
 

Bug in ksh 88[df] "print -u2" and/or "read" statement.

Post by lawrence.v.cipria » Thu, 01 Aug 1991 00:19:54




>I emailed the bug report to him; I'll post his response if any.  I was
>able to reproduce it on an AT&T 6386/25 WGS running ksh88f.

Here is Korn's response to this problem report:

When the last print doesn't have a new-line, ksh tries to use the
string as a prompt.  However, if you are using an edit mode, ksh
will truncate prompts on the left based on the value of COLUMNS so
that there is room on the screen for your answer.  I don't remember
how may columns it will allow for a prompt before truncating, I think
that it is approximately 7.

There are two ways around this problem.  First of all you can disable
edit mode within the script with
        set +o emacs +o vi
If you do this then the user will not be able to make corrections
with emacs and/or vi.

The other thing that you can do is to increase the width of COLUMNS.

David Korn
ulysses!dgk

--

"Fight fire with fire, I always say." -- Bugs Bunny

 
 
 

Bug in ksh 88[df] "print -u2" and/or "read" statement.

Post by Marnix A. van Amme » Fri, 02 Aug 1991 23:36:53





>>################################# Start of script ###########################
>>print -u2  "I need to ask you a few questions."
>>print -u2  "Have you already filtered the data into a file (y/n) ? \c"
>>read       Answer
>>print -u2  "Before proceding, please enter file type [hex/octal/binary]: \c"
>>read       FileType
>>################################# End of script #############################

>Here is Korn's response to this problem report:

>When the last print doesn't have a new-line, ksh tries to use the
>string as a prompt.  However, if you are using an edit mode, ksh
>will truncate prompts on the left based on the value of COLUMNS so
>that there is room on the screen for your answer.  I don't remember
>how may columns it will allow for a prompt before truncating, I think
>that it is approximately 7.

>There are two ways around this problem.  First of all you can disable
>edit mode within the script with
>    set +o emacs +o vi
>If you do this then the user will not be able to make corrections
>with emacs and/or vi.

>The other thing that you can do is to increase the width of COLUMNS.

>David Korn
>ulysses!dgk


I heard a reply from Mr. Korn was also emailed to me, but our mail
system here has been on the blink for quite a while and a lot of mail
from the outside doesn't seem able to get to us.

I've tried the "set +o emacs +o vi" work-around, but I *still* had the
trouble.  However, I did find out that if I unset EDITOR in my
environment, the problem would go away.

Work-arounds or not, ksh seems to be putting a RETURN character in
some text when it shouldn't.  Ksh is adding up the characters of
two strings to get to the COLUMN position, without paying attention
to the fact that a RETURN had already been sent to the terminal
after the first string (because of the user's response).

Some of you who could *not* reproduce the bug in my original
posting should see if you have "EDITOR" set in your environment.
If not, try setting it to "vi" and see if the bug shows up.

The best workaround I see for now is to unset EDITOR at
the beginning of any ksh script where there are prints and reads
to and from the user's terminal.  I don't like the solution of
setting COLUMN high (how high?).  I don't even like the "unset EDITOR"
solution, but it seems the best one for now.

Marnix A. van Ammers
Pacific Bell ESAC
WORK: 415-645-5196
UUCP: ...!uunet!pacbell!pb1esac!mavanamm
-------------------------------------------------------------------------
Mijn broer is gek.  Mijn hond ook.  Maar niet mijn poes.

 
 
 

Bug in ksh 88[df] "print -u2" and/or "read" statement.

Post by Mark Lan » Sun, 04 Aug 1991 05:09:15



    [ much discussion about wierd behavior of ksh on some systems deleted ]

    I've tried the "set +o emacs +o vi" work-around, but I *still* had the
    trouble.  However, I did find out that if I unset EDITOR in my
    environment, the problem would go away.

    Some of you who could *not* reproduce the bug in my original
    posting should see if you have "EDITOR" set in your environment.
    If not, try setting it to "vi" and see if the bug shows up.

I was one of those who could not reproduce the error.
I have:
        1)  EDITOR=/usr/bin/ex
        2)  VISUAL=/usr/local/bin/emacs
        3)  set -o vi

so this is not the whole story.

                        --Mark--

 
 
 

1. Bug in ksh 88[df] "print -u2" and/or "read" statement?

This problem may exist in ksh version E as well, but for sure it's
in ksh versions D and F.  The trouble is that the ksh will replace a
character with the return character '\015' in the middle of some
text I'm trying to send to standard error output.  The following
script illustrates the problem:

################################# Start of script ###########################
print -u2  "I need to ask you a few questions."
print -u2  "Have you already filtered the data into a file (y/n) ? \c"
read       Answer
print -u2  "Before proceding, please enter file type [hex/octal/binary]: \c"
read       FileType
################################# End of script #############################

The last print statement has the 'l' in "please" changed to a return
character so that the resulting screen looks something like:
-------------------------------------------------------
I need to ask you a few questions.
Have you already filtered the data into a file (y/n) ?
ease enter file type [hex/octal/binary]:
-------------------------------------------------------

I have duplicated this on a 3B4000 and on a 3B15 running SYSV,
release 3.  I have the same trouble even with my "ENV" variable
unset and starting up a fresh ksh.

With trial and error I have found that the trouble is affected by
the COLUMN variable.  I have the problem with no COLUMN variable set
or with COLUMN set to 80 or less.  Ksh's behavior is similar to what
happens when you are on the command line editing a line longer than
COLUMNS characters and you get to the right edge of the screen (in
vi mode anyway).  You have to be "print"ing with "-u2" and you have
to do read's for this bug to show.  If you put almost any command
prior to the last read, the trouble will clear.  Simple deleting the
last read will also get rid of the trouble.

Is this a known bug?  Can other's duplicate this as well?

Thanks for any information.

Marnix A. van Ammers
Pacific Bell ESAC
415-645-5196

2. Another IE failure? SVG?

3. GETSERVBYNAME()????????????????????"""""""""""""

4. CM 205 no good for linux?

5. """"""""My SoundBlast 16 pnp isn't up yet""""""""""""

6. FAT32 & Long File Names

7. Problems with "df" and "du" on "/var"

8. How to setup the ISP connection

9. Using "if" in "ksh" to change "for loop" values....

10. Type "(", ")" and "{", "}" in X...

11. ksh - no "read" from pipe, but not common "subshell" issue

12. Strange effect in "read" with "ping" (ksh)

13. Does FreeBSD 3.0' ksh support "print" and "function" ?