0

On windows, the programmer could do something like: system("ls > outputFile.txt")

Is there a platform independent way to access the command line, or a least a way to determine which platform the program is being executed on (because calls for the same functionality vary quite a bit)?

enter image description here

sherrellbc
  • 4,650
  • 9
  • 48
  • 77

2 Answers2

2

The system(3) function is standard ANSI C, it's already platform-independent. Any conforming C implementation will allow you to call it to run the system default command line processor/shell application. Of course, the actual programs you can run will vary from system to system (e.g. dir only works on Windows, while ls usually works on Unix-like platforms).

Adam Rosenfield
  • 390,455
  • 97
  • 512
  • 589
  • I see. Will it be handled at compile-time if the program attempts to call an unsupported command? – sherrellbc Jan 15 '14 at 20:23
  • 1
    @sherrellbc no, the compiler has no way of knowing what will be a "valid" command or not. – TypeIA Jan 15 '14 at 20:24
  • Right. So given that these system calls are internal (i.e. the command prompt is not opened), are these unsupported calls simply passed through with the program continuing as if they were executed properly? That could be a bit difficult to debug, especially if you attempted to read an `outputFile.txt` that was never created! – sherrellbc Jan 15 '14 at 20:27
  • 1
    @sherrellbc " at compile-time" -- Do you understand what compile-time *is*? Your question suggests that you don't. I suggest that you look at "Return Value" at http://linux.die.net/man/3/system ... return values are returned, and would be examined, at *run* time, not *compile* time. By using very wrong language you are being misled by the responses. – Jim Balter Jan 15 '14 at 20:32
  • 1
    @sherrellbc "That could be a bit difficult to debug" -- really, no. Get more programming experience before imagining that you know what it means for something to be difficult to debug. "especially if you attempted to read an outputFile.txt that was never created!" -- It's trivial to find out that a file doesn't exist. From that, the inference that it was never created follows immediately. – Jim Balter Jan 15 '14 at 20:39
  • I was referring to at *compile* time the calls being made to the system, unsupported on that system, would result in an error - I was informed this is not the case by something that is quite obvious. Further, by "difficult to debug" I was not referring to the obvious fact that the file attempting to be read would not have been created, but rather to the potentially unknown *reason* behind it. That is, it may be difficult to figure out why a file was not created because system calls being made are not supported - a simple mistake if one is not immediately familiar with a system. – sherrellbc Jan 15 '14 at 20:48
  • if you need to assure that the program is running and creates a file, you need to check CreateProcess on Windows, or i think fork on linux, and it's not platform independent but gives you the certainty you need – fernando.reyes Jan 15 '14 at 21:09
1

system() itself is a standard C function defined in stdlib.h. The way it interprets its argument, though, is not standard (e.g. ls in UNIX, dir in Windows/DOS, etc.). If you're really asking whether there's a platform-independent way to list the files in a directory, the answer is (unfortunately) no. Some libraries do provide portable (to some degree) implementations, most notably Boost: How can I get the list of files in a directory using C or C++?

Community
  • 1
  • 1
TypeIA
  • 16,916
  • 1
  • 38
  • 52