? Conventions in CUI programs ?

[twitchyliquid64]

Hi all,

I'm developing a console program (program.exe) that takes file A and produces file B.

What I wanted to know is what is the convention for passing files as arguments on the command line?

In other words is it convention to do:

program.exe "C:folderfile.abc"

or is it convention to use the CWD:

cd c:folder
Program.exe file.abc

Both will require different code internally. I want to know this because I am developing a program and need to know which to use.

Also, is it convention to pass command line switches before or after the main input argument?

Thanks in advance.

[BrewManNH]

If it's a well written program, it will take a file not being able to be found as an error and tell the user that.

So, you make it so that the full path should be included if not in the same folder, and if just the file name is passed and the program can't find it, tell the user. Example, the file is is C:Tempsomefile.txt, the user starts the program from the desktop with the command line Program.exe "somefile.txt", the program can't find the file on the desktop so it's an error condition. If you make the program so that it requires the file to be in the C:Temp folder and you CD to that folder you're going to have users unhappy because they don't have a C:Temp folder.

[wraithdu]

I would add that in many of my apps that take files as commandline input (regardless if they are CUI or not), check the file with FileExists() and if true, use _PathFull() to convert whatever has been given to you to a fully qualified path. _PathFull follows the same rules as FileExists for paths, so you're guaranteed good path input to work with afterwards.

[twitchyliquid64]

If it's a well written program, it will take a file not being able to be found as an error and tell the user that.

So, you make it so that the full path should be included if not in the same folder, and if just the file name is passed and the program can't find it, tell the user. Example, the file is is C:Tempsomefile.txt, the user starts the program from the desktop with the command line Program.exe "somefile.txt", the program can't find the file on the desktop so it's an error condition. If you make the program so that it requires the file to be in the C:Temp folder and you CD to that folder you're going to have users unhappy because they don't have a C:Temp folder.

So basically I should require users to put their files in the current working directory, and just call program.exe file.a ?

And if it cannot be found, report error condition.

I would add that in many of my apps that take files as commandline input (regardless if they are CUI or not), check the file with FileExists() and if true, use _PathFull() to convert whatever has been given to you to a fully qualified path. _PathFull follows the same rules as FileExists for paths, so you're guaranteed good path input to work with afterwards.

This is in C++. is there a Microsoft function call equivalent?

[wraithdu]

PathCanonicalize in shlwapi.dll is pretty close in that it will resolve paths with . and .. However it will not prepend any root path, so if you are given a path with no root, you'll have to manually prepend the working directory first.

Edit...

PathCombine in shlwapi.dll is what you want. It will both combine two paths (a root and a relative path) and resolve relative path components . and ..

Edited October 3, 2012 by wraithdu

[BrewManNH]

So basically I should require users to put their files in the current working directory, and just call program.exe file.a ?

And if it cannot be found, report error condition.

No, what I said was that your program should take the command line parameter and see if it exists, if there's no path for the file and it's not located in the same place as your program then it doesn't exist. In cases like that you check for the file, see it's not there, tell the user that the file can't be found and to use the full path of the file or you can't process it. This way your users can put their files anywhere they want and you don't have to hard code the locations in the program.

[guinness]

Wouldn't _PathFull be GetFullPathNameW in kernel32.dll? Though you would have to set the working directory to the base path. How I do it in AutoIt with WinAPIEx.au3.

Func _GetFullPath($sRelativePath, $sBasePath = @WorkingDir)
    Local $sWorkingDir = @WorkingDir
    FileChangeDir($sBasePath)
    $sRelativePath = _WinAPI_GetFullPathName($sRelativePath)
    FileChangeDir($sWorkingDir)
    Return $sRelativePath
EndFunc   ;==>_GetFullPath

Edited October 3, 2012 by guinness

[wraithdu]

Only problem is that FileChangeDir fails if the directory doesn't exist. So you can't use the function in a 'theoretical' sense. Where _PathFull and PathCombine both work without root actually existing. The drawback to PathCombine is the MAX_PATH limit. So all options given, I use _PathFull in AutoIt. GetFullPathName would probably be the better choice in C however, especially since he's requiring the files to exist anyway.

[guinness]

Only problem is that FileChangeDir fails if the directory doesn't exist. So you can't use the function in a 'theoretical' sense. Where _PathFull and PathCombine both work without root actually existing. The drawback to PathCombine is the MAX_PATH limit. So all options given, I use _PathFull in AutoIt. GetFullPathName would probably be the better choice in C however, especially since he's requiring the files to exist anyway.

Valid point wraithdu.

[Ascend4nt]

twitchy, at the very least, when presented with a file on the command-line, check the current directory [GetCurrentDirectory] AND the executable directory [GetModuleFileName minus the executable]. There's also the possibility that what they entered is available in the 'App Paths' registry key, or can be found if appended to the %PATH% environment variable [PathFindOnPath]. Those extra checks are up to you though.

Btw, if you use 'App Paths', you'll need to do extra processing (using the executable name in the default value, adding paths to the environment from the 'Path' value) if you call a process using CreateProcess - or just use ShellExecute to let the O/S do that extra junk.

*edit: forgot to mention, the extra check for 'App Paths' is only for executable files

Edited October 3, 2012 by Ascend4nt

[Richard Robertson]

In the long run it shouldn't matter whether or not the file is fully qualified or relatively qualified. The program should work in all situations as long as the provided path is valid.

You should also be able to mix fully qualified and relative paths within a single command line (if you take more than one file that is).

[AdmiralAlkex]

Both will require different code internally. I want to know this because I am developing a program and need to know which to use.

No? Why would you? I'm with Richard, it should just work. That is how other console applications are doing it.