Bug/Enhancement- Inconsistent use of "LogPath" parameter

[incansvl]

The PSLogging examples here- https://9to5it.com/powershell-logging-v2-easily-create-log-files/ show the API as follows:

1. Start-Log -LogPath “C:\Windows\Temp” -LogName “Test_Script.log” -ScriptVersion “1.0”
2. Write-LogInfo -LogPath “C:\Windows\Temp\Test_Script.log” -Message “This is a new line which I am appending...”
3. Write-LogWarning -LogPath “C:\Windows\Temp\Test_Script.log” -Message “This is a warning message.”
4. Write-LogError -LogPath “C:\Windows\Temp\Test_Script.log” -Message “This is an error message.” -ExitGracefully $False

In 3 out of 4 of these examples (lines 2-4) the parameter LogPath is the full absolute pathname of the log file (FullName in Powershell parlance). However in "Start-Log" the path of the file is passed in two separate parameters, LogPath and LogName.

I incorrectly assumed this was demonstrating a consistent flexibility in the API. It seemed reasonable that the caller could provide EITHER-

1. A full pathname (only) via LogPath
2. A LogPath and a LogName (which will be combined via a JoinPath before use)

However this is not the case. If I call Start-Log with a parameter LogPath only it comes back with the prompt for the missing parameter-

Start-Log at command pipeline position 1
Supply values for the following parameters:
LogName:

This seems like an unnecessary inconsistency. It means the caller has to initialise the module with LogPath and LogName as separate variables, and then do their own JoinPath to have the full path available for the subsequent API functions.

It also means that if you misunderstand this wrinkle, as I did, while putting a Powershell script in a background process, that process will hang because of the "missing parameter" prompt.

The good news is this is very easy to fix, and in the process (IMHO) make the API both more consistent, and more flexible.

Proposed Solution

Simplest approach-

1. Make the LogName parameter optional. If LogName is omitted, LogPath is expected to be the full pathname of the log file (just like the other API calls). Note-you can even leave the existing "JoinPath" in the module code, it will simply ignore the null value passed to -ChildPath.

More flexible approach-

1. Make both LogPath and Logname optional parameters
2. Support EITHER or BOTH of these parameters in all the API interfaces of the module
3. The module would follow these rules-

a. If NEITHER LogPath or LogName are provided as parameters, that's a "no path specified" error
b. If ONE of these parameters is provided, it should be set to the full pathname of the log file and the module will use it
c. If BOTH LogPath or LogName are provided as parameters, the module uses Join-Path on them and tries to resolve the result as the pathname of the log. Note: If the user does something daft like provide an absolute path in both parameters, then Join-Path will produce a nonsense pathname and the result I assume will fail at file creation time.