Infrastructure Software

Have you tried the following:

./start_of_my_script ... \
contination of parameters \
more continuation ...

I believe by breaking it up with the '\' you can get around the character limitation.

Hello,

thank You for reply - temporarly I used "\" character to "split" command - it works, but I want send all in one line.... :/

Maybe you should just put the whole thing in a shell script. What is causing the command to be so long? Do you have to call the absolute path?

Hello,

unfortunately I cant use script - I use shell as a one of connection types.
All scripts I writes in Expect and from that I send all commands.Commands are creates dynamically. I send "snmpset" command, which have more characters than allowed for sh size.

Cheers,
Jacek

Hello.

I do not understand if I understood your problem correctly.

I tried the following script:

#!/bin/sh
# The following line is more than 3000 characters long
echo 0 1 2 3 ... 1000

It works well on Solaris 10/x86 and Solaris 9/Sparc.

Do you have any example script?

Martin

Hi,

simple example :



#!/usr/mdstest/bin/expect -f


spawn /bin/sh
set cmd "snmpset -v 2c -c ptcBRASprovisioning 10.18.124.17 .1.3.6.1.4.1.4874.2.2.8.1.3.3.1.3.184549545.33.55551 i 4 .1.3.6.1.4.1.4874.2.2.8.1.3.3.1.4.184549545.33.55551 i 103355551 .1.3.6.1.4.1.4874.2.2.8.1.3.3.1.5.184549545.33.55551 i 2 .1.3.6.1.4.1.4874.2.2.8.1.3.3.1.6.184549545.33.55551 i 0\r"

puts $cmd
send $cmd


expect {
-re "Timeout: No Response from" {
puts "Can't connect to ATM"
}

-re "Was that a table" {
puts "Invalid name of table"
}
-re "Error in packet\.\[^\n\]+" {
puts " pierszy |$expect_out(buffer)|"
expect {
-re "Reason:(\[^\n\]+)" {
puts "BEGIN$expect_out(1,string)END";
}
}
expect {
-re "Failed object\[^\\$\n\]+" {
puts "ERR in packet - ||$expect_out(buffer)||"
}
}

}
-re "SNMPv2\n-SMI::enterprises\[0-9\\.\]+\[ \]+=\[ \]+INTEGER:\[0-9 \r\]+" {

puts "END TRANSMISSION "

}

-re "\\$ " {
puts "PROMPT"
}
default { puts "default" }
}


When it I ran script I got ( line from send command ):
snmpset -v 2c -c ptcBRASprovisioning 10.18.124.17 .1.3.6.1.4.1.4874.2.2.8.1.3.3.1.3.184549545.33.55551 i 4 .1.3.6.1.4.1.4874.2.2.8.1.3.3.1.4.184549545.33.55551 i 103355551 .1.3.6.1.4.1.4874.2.2.8.1.3.3.1.5.184549545.33.55551 i 2 .1.3.6.1.4.1.4874.2.2.8.1.$ PROMPT

another simply test : from bash invoke /bin/sh and try to paste line :
snmpset -v 2c -c ptcBRASprovisioning 10.18.124.17 .1.3.6.1.4.1.4874.2.2.8.1.3.3.1.3.184549545.33.55551 i 4 .1.3.6.1.4.1.4874.2.2.8.1.3.3.1.4.184549545.33.55551 i 103355551 .1.3.6.1.4.1.4874.2.2.8.1.3.3.1.5.184549545.33.55551 i 2 .1.3.6.1.4.1.4874.2.2.8.1.3.3.1.6.184549545.33.55551 i 0
- it has more than 257 characters

Cheers,
Jacek

You might want to try spawning /bin/bash instead of /bin/sh.
The gnu variant of tools tend to be more resiliant to issues like buffer lengths.

I tried with

bash-3.00$ which bash
/pkg/bin/bash


but I have the same results....

On my Blade-1000 I was able to re-produce the problem:

Three "shells" are involved in your script:
- Bash
- Tcl/TK
- Expect

The "send" command is used to send data from Tcl/TK to Bash. This is done using a pseudo-tty, not using pipes (as it is done normally).

All TTYs (terminal, console, pseudo-tty, telnet, ...) seem to be limited to 256 characters when being used in "canonical" (line-wise) mode.

None of the programs (Bash, Tcl/TK, Expect) have a limitation to 256 characters.

The solution would be calling the command line directly (something like "spawn $cmd"), if possible using pipes instead of a pseudo-tty (using "open |xxx" instead of "spawn").

Note: Investigating your problem I had my first experiences with Tcl.

Martin

Hello,

Yes You are right, none of them - bash, tcl, Expect havn't limitations - only shell has it.
For that reasons I ask here, which system parameter should be changed to fix it...

I think that MAX_CANON, but I not sure. What do You think ? Do You know any side effect of increasing this parameter ?

Cheers,
Jacek

Hello.

You are right. It is MAX_CANON.

However looking on the OpenSolaris sources you can see that you would have to re-compile the ldterm kernel module because the MAX_CANON parameter is hard-coded into this module.

Martin

Hello,

Thank You for all help and explanations.

Cheers,
Jacek

Another option is to insert this expect command before spawning the process:

set stty_init raw

for more information, see

https://www.pooryorick.com/secure/wiki/Pub/UnixTroubleshootingInteractiveInputLineLength