3 ms·

> Today, processes are nearly always launched by other programs, but despite this, must still serialize the argument array into a string as though a human had t

• roelschroeven 5y ago
  More fundamental or not, an array of arguments is much more practical than a string, hopefully well-formed, thrown at you. I can't think of any case where you would not want to split up that string in separate arguments. (I'm not talking about the case where you control both parent and child program; then you can do whatever you want and even use e.g. JSON. But in the general case, parents expect children to accept argument lists and children expect to be passes argument lists.)
  • zokier 5y ago
    > I can't think of any case where you would not want to split up that string in separate arguments Random example, but jq takes its input expression non-tokenized (i.e. as a single argument) while in contrast find takes its expression as a sequence of tokens (i.e. an array of arguments).
    • formerly_proven 5y ago
      jq actually has a bunch of flags but they're not commonly used.
• xg15 5y ago
  True in principle: On Windows, the fundamental data structure for command line args is an array, while on linux it's an array of strings. I think you could argue that an array is a better-suited data structure than a single string though, as most programs take more than a single argument on the command line. Also note than on unixy systems, the command line is only "serialized as an array" when you run a command from the shell. (And then the shell does the serialisation, not the OS). If a program is launched by another process, the command line is always an array, never a string.
  • zokier 5y ago
    > Also note than on unixy systems, the command line is only "serialized as an array" when you run a command from the shell. (And then the shell does the serialisation, not the OS). > If a program is launched by another process, the command line is always an array, never a string. Maybe an example illustrates what I meant by serializing the command-line expression. Many programs take key-value arguments in the form `--key value`, so conceptually that is not an array but a serialization of key-value mapping into an array. You could imagine that an higher level wrapper to call that program could be represented as `exec_foo({"key": "value"})`, and that argument map is then serialized into the string array `--key value`. Of course that sort of serialization of higher-level concepts (like key-value mappings or subcommands or whatev) is very much target program specific. Which leads to the main argument that in any non-trivial cases you need to serialize the higher-level "api" (which might be key-value mapping, or something more complex) to the "wire format" which can be either array of strings or single string; conceptually that is fairly minor difference.
• thristian 5y ago
  While there's no good reason for the Platonic ideal of a command-line to have one particular shape or another (a string! a list! a tree! a graph!) a vast number of Windows and Unix apps are written in C or C++, which demand the standard main() entry point be given an array of strings. Even completely Windows-native apps that use WinMain() instead of main() still often need to take a filename on the command-line, or want to handle command-line switches, for which they need to lex the command-line string into an array of tokens.
  • rossy 5y ago
    Even C#, a formerly Windows-only language, has Main(string[] args)
• formerly_proven 5y ago
  When talking about command line programs, we talk about discrete arguments. "The first argument of copy is the source, the second is the destination".
• marcosdumay 5y ago
  Hum. A command line, the thing you write on shells, is a command followed by a series of parameters. That's its form on Unix, and DOS/Windows didn't deviate from it in any way. It could have created a different interface, but it didn't.