bin/13274: /bin/sh 'read' command does not work correctly

Reply via E-mail

From:

Thomas Gellekum <tg@ihf.rwth-aachen.de>

Date:

23 Aug 1999 14:13:38 +0200

aa8vb@ipass.net writes:

> Please fix /bin/sh so that the default behavior of the "read"
> command is such that it merges lines ending with a trailing '\'
> (i.e. like it behaves now only if -e is specified). Thanks.

What's the verdict of the sh gurus? If I understand SUSV2 correctly,
Randall is right, and the standard conforming behaviour is to continue
reading. In that case we should kill the `-e' flag (see diffs below),
IMHO.

tg

Download patch-1.diff

Index: miscbltin.c
===================================================================
RCS file: /home/ncvs/src/bin/sh/miscbltin.c,v
retrieving revision 1.19
diff -u -r1.19 miscbltin.c
--- miscbltin.c  1999/05/08 10:21:56     1.19
+++ miscbltin.c  1999/08/23 12:30:21
@@ -71,8 +71,7 @@
 
 
 /*
- * The read builtin.  The -e option causes backslashes to escape the
- * following character.
+ * The read builtin.
  *
  * This uses unbuffered input, which may be avoidable in some cases.
  */
@@ -85,7 +84,6 @@
         char **ap;
         int backslash;
         char c;
-        int eflag;
         char *prompt;
         char *ifs;
         char *p;
@@ -98,18 +96,14 @@
         struct termios told, tnew;
         int tsaved;
 
-        eflag = 0;
         prompt = NULL;
         tv.tv_sec = -1;
         tv.tv_usec = 0;
-        while ((i = nextopt("ep:t:")) != '\0') {
+        while ((i = nextopt("p:t:")) != '\0') {
                 switch(i) {
                 case 'p':
                         prompt = optarg;
                         break;
-                case 'e':
-                        eflag = 1;
-                        break;
                 case 't':
                         tv.tv_sec = strtol(optarg, &tvptr, 0);
                         if (tvptr == optarg)
@@ -184,7 +178,7 @@
                                 STPUTC(c, p);
                         continue;
                 }
-                if (eflag && c == '\\') {
+                if (c == '\\') {
                         backslash++;
                         continue;
                 }

Reply via E-mail
From:	Sheldon Hearn <sheldonh@uunet.co.za>
Date:	Mon, 23 Aug 1999 15:39:35 +0200
If you want to score OpenGroup brownie points, reverse the meaning of the -e option and call it the option -r option. The OpenGroup Single UNIX Spec offer the -r option: Do not treat a backslash character in any special way. Each backslash is considered to be part of the input line. Ciao, Sheldon.

Reply via E-mail
From:	Tim Vanderhoek <vanderh@ecf.utoronto.ca>
Date:	Wed, 25 Aug 1999 09:12:13 -0400
On Wed, Aug 25, 1999 at 08:39:44AM +0200, Sheldon Hearn wrote: > > > read [-er] [-p prompt] [-t timeout] variable ... > > I don't think it's that simple. I think the style of manpage is to > declare the options to builtins in the order in which the following > description treats them. You're wrong. See for example the hash description. The only one that might conceviably support your argument is the ulimit builtin, which is that way because it's alphabetisized. The fc builtin is also alphabetisized, except for the last couple entries, which run counter to your theory. I'll not that the hash synopsis is wrong, though. It should be hash [-rv] [command ...] Of course, the ulimit builtin is also a bad example: it was added by J in rev 1.4 (ie. not in the original manpage). For that matter, read was touched by msmith in another rev. You can make an argument for read [ -er ] [ -p prompt ] [ -t timeout ] variable ... which was the original style, but that style is no longer. While we're here, variable appears to be optional. I don't know what the purpose of read without variable is, though... -- This is my .signature which gets appended to the end of my messages.

State Changed
From-To:	open->closed
By:	tg
When:	Thu Sep 2 05:10:21 PDT 1999
Why:	The `read' builtin has been fixed in -current and -stable.