1

I have the following shell script to read lines from terminal

#!/bin/bash

while read line
do
if [ -z ${line} ]
then
    break
fi
echo ${line}
done

I cannot enter more than 256 characters. The terminal doesn't allow me to do so (Terminal doesn't print anything beyond 256 characters, not even new line. only thing it allows is backspace)

$ ./echo.sh
wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww

Im using solaris 10 OS terminal used is putty bash version 3.2.52

Is this a limitation in bash, or putty? I know to break my input into several lines, but I need to know if there is way to overcome maximum number of characters entered for read command as input

vibz
  • 157
  • 1
  • 12
  • 1
    @KrisRoofe - the question you've linked is about the length of the *command line*, not the length of input for the `read` command. While this may be a duplicate, I don't think it's a duplicate of the question you've linked to. – ghoti May 03 '17 at 02:36
  • @vibz, what operating system and version of bash are you using? I can't replicate the problem you're having. Can you clarify what "I cannot enter" means? Are you getting some error? If so, what error? – ghoti May 03 '17 at 02:42
  • yes as @ghoti said, its about the limitation on the length of input for read command, not about maximum length of command that can be typed – vibz May 03 '17 at 02:43
  • 3
    As an unrelated aside, `[ -z $line ]` doesn't do what you think it does; use `[ -z "$line" ]` instead. When your line variable is empty, `[ -z $line ]` becomes `[ -z ]`, which is equivalent to `[ -n -z ]`, so it returns true for *entirely* the wrong reason. Moreover, if `line='foo -o 1 = 1'` were set, you'd see a truthy return when the variable being tested wasn't empty at all. (This whole class of bug will be caught by http://shellcheck.net/; consider using it habitually). – Charles Duffy May 03 '17 at 02:49
  • @ghoti I've updated the question with details. Solaris 10, bash 3.2.52. – vibz May 03 '17 at 02:50
  • There are implementation defined limits that you can query using `getconf`. This is the [IEEE specification](http://pubs.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html). – alvits May 03 '17 at 02:54
  • 1
    @tripleee, the proposed dupe appears to be dealing with command-line argument list length, rather than terminal content consumed by `read`. Am I missing something there? – Charles Duffy May 03 '17 at 03:44

1 Answers1

6

This is limitation in the OS terminal drivers.

We normally take it completely for granted, but when you enter hi<Backspace>ello and press enter, the process just reads hello.

The terminal driver makes this happen by storing the line in memory, and then deleting the last character in that buffer when you press Backspace. The buffer used for this has some human scale size. On Linux it's 4096 bytes, for comparison.

You can get around this by disabling line editing:

stty -icanon

read will now read more data at a time, but if you press Backspace, the application will actually read a backspace character instead of the final line.

that other guy
  • 116,971
  • 11
  • 170
  • 194
  • thanks for the reply. But this introduces a new problem. `Enter` is now read as a character, leaving `if [ -z ${line} ]` never being executed, thus while loop never terminating – vibz May 03 '17 at 06:18