in reply to Re: Problem with STDIN input
in thread Problem with STDIN input

Hi ikegami, Thanks for the input.I too suspect that it should be shell's limitation.Not sure if the length is controlled by a environment/shell varaible of my ksh(*NIX box) which I strongly suspect.I am really after this Env/shell varaible whcih I belive if I can export prior to taking the input then I should be able to input more characters. FYI:As you suggested reading from file would be ideal but the requirement is to take a direct input from command line.The users would be invoking the script from a menu of options where they would be asked for the message through th e command propmt.They are not alloed to create files on unix box. By the way would you mind if I ask you what actually is the line doing: perl -le'print "x" x ($ARGV[0]-1)' 100 | perl -le'print length <>'

Replies are listed 'Best First'.
Re^3: Problem with STDIN input
by ikegami (Patriarch) on Jun 12, 2009 at 17:20 UTC

    I too suspect that it should be shell's limitation.

    "too"? I didn't mention the shell at all, but I suppose it could also be the shell's fault.

    what actually is the line doing

    The first perl creates a long string which is sent to the second perl's STDIN as if someone had typed it. It shows that Perl has no problem reading a line one million bytes long.

      Understood the meaning of the line in perl.Thx. The problem got solved about the number of character inputs when my unix administrator ported the program to another unix box with bash.So , it really was a problem/limitation with the env (the unix env where i was testing the script)and not perl.Now , the script is taking any length of input in the new unix box and the problem is solved. Thanks to all of you for your inputs. However , Though perl script problem is solved but just for my knowledge sake I am still "googling" around to know what was the problem or how could the limitation be removed in Unix env. where I was developing the script. Gyatso