command line maximum length

[rhoopc]

hello all ... much appreciate the help and information ...

i'm new to ibm's and recently encountered a command line max length of around 200. i thought this a little small and contacted ibm support and they said this is *the* max.

this doesn't seem like much of a command line buffer and i was curious the thoughts of people with more experience with ibm aix:
1) is this sound right?
- and -
2) can i make it more?

if this is true i wonder how some of the longer compile lines of a gcc compile succeed?

we have two p680's and two p690's - one is running 4.3 and the others are running 5.1.

many many thanks,
ross

 

[avadh]

Hello,
If you are running GCC and it is gnu C++ compiler then IBM does not have any obligation to you.

As you have spend lot of money on hardware. You should have used little bit of that money to use IBM's C or C++ compiler.

 

[dobbyn]

If you have a command line that will be longer than 200 chars, you should put it in a script file and execute the script. We often do this for long compile lines where I work.

I don't see how avadh's comment is helpful...

 

[gheist]

Command line length depends on your shell and app, exec limitations can be overridden on AIX 5.1 (not 4.x) in smitty chgsys

 

[rhoopc]

thanks for the info everybody - much much appreciate it.

we are using ibm's compilers - although not successfully yet. the gnu gcc compile was our attempt at a complex compile and it failed miserably. i'm wading through "install apar hell" right now trying to get these very expensive ibm c/c++ compilers to work for us.

i'm going to try dobbyn's idea with a script - i typically use perl and "system()" so i overlooked this - thanks for the idea.

i put the largest number i could in the smitty chgsys to get to the limit we have (it was originally around 100 bytes). i'll verify we didn't miss something here.

do appreciate the help all - many thanks,
ross

 

[Yegolev]

There are other issues with line-length to watch for, such as the 2048-char limit in AIX vi which we occasionally have problems with. I installed ViM to get around that, and the use of vi in the first place was a workaround for a line-length issue in smit. I believe the max length in smit is also 2048 chars, probably because it uses the same ed as vi.

 

[rhoopc]

many thanks everybody - i think i'm pulling a "no brainer", we can probably "close" this one.

here's where i think i made my mistake ... <please let me know if i'm thinking wrong here>

i'm confusing command line length from a telnet session with the size of the strings that can be passed to an exec statement.

as gheist pointed out you can control the 4K buffers via smitty (&quot;System Environments&quot; then &quot;Change / Show Characteristics of Operating System&quot; ... ). we have plenty of space available for the &quot;argument list&quot; (try using help [F1] with smitty to get some messages) - we have 128 4K blocks available.

my critical mistake was confusing what i was typing at a command line as &quot;the limit&quot; - i should have tried a korn shell to see what the limit would be that way. i'm betting the command line in a telnet is a buffer that's fairly small - how many people would actually type in 400 bytes? most would probably put that in a script (like i should have ... ).

many thanks for the help everyone,
ross

 

[gheist]

That is main assertion by programmers done making their apps - timeline was pressing them, so they put fixed length buffers in their programs every place (ie. who will have more than 2048 files in directory, who will type more than 400 chars, who uses files larger than 2G etc,etc)