How long can my command-line be?

bartonski · 11-24-2009, 06:56 AM

Quote:

Originally Posted by i92guboj

The only shell that I remember right now that allocates environment space dynamically is the os/2 one, as far as I can remember. That doesn't mean there aren't more around that can do it...

The Hurd? (/me ducks)

bartonski · 11-24-2009, 07:22 AM

Quote:

Originally Posted by i92guboj

Shell languages are as they are for a reason, they make a lot of assumptions to make the scripting a lot easier, and the limited environment is one of these assumptions.

on a more serious note, this is almost undoubtedly the right design decision. One of the fundamental principles of Unix is that spawning processes is computationally inexpensive.

Eric Raymond puts it best in The Art of Unix Programming

Quote:

Cooperating Processes

In the Unix experience, inexpensive process-spawning and easy inter-process communication (IPC) makes a whole ecology of small tools, pipes, and filters possible. We'll explore this ecology in Chapter 7; here, we need to point out some consequences of expensive process-spawning and IPC.
The pipe was technically trivial, but profound in its effect. However, it would not have been trivial without the fundamental unifying notion of the process as an autonomous unit of computation, with process control being programmable. As in Multics, a shell was just another process; process control did not come from God inscribed in JCL.
-- Doug McIlroy
If an operating system makes spawning new processes expensive and/or process control is difficult and inflexible, you'll usually see all of the following consequences:

Monster monoliths become a more natural way of programming.
Lots of policy has to be expressed within those monoliths. This encourages C++ and elaborately layered internal code organization, rather than C and relatively flat internal hierarchies.
When processes can't avoid a need to communicate, they do so through mechanisms that are either clumsy, inefficient, and insecure (such as temporary files) or by knowing far too much about each others' implementations.
Multithreading is extensively used for tasks that Unix would handle with multiple communicating lightweight processes.
Learning and using asynchronous I/O is a must.

These are examples of common stylistic traits (even in applications programming) being driven by a limitation in the OS environment.
A subtle but important property of pipes and the other classic Unix IPC methods is that they require communication between programs to be held down to a level of simplicity that encourages separation of function. Conversely, the result of having no equivalent of the pipe is that programs can only be designed to cooperate by building in full knowledge of each others' internals.

Angus · 11-24-2009, 08:31 AM

Quote:

Originally Posted by catkin

And have exactly the same issue!

It's been a long time since I have. Usually when I call a function wrong, the compiler lets me know right away. I used to have behavior I didn't expect when improperly using the *printf() family, but gcc has features that make that much safer.