Linux: openSUSE Tumbleweed
Installed from distribution packages
│ └── test_a.wav
2 directories, 2 files
/tmp/audacity/$ cd a/
/tmp/audacity/a/ $ audacity test_a.wav &
/tmp/audacity/a/ $ cd ../b
/tmp/audacity/b/ $ audacity test_b.wav
Expected behavior: Audacity opens /tmp/audacity/b/test_b.wav (in a new window)
Actual behavior: Audacity displays a message box “test_b.wav could not be found. It has been removed from the list of recent files.”
- Specifying the full path name (“audacity /tmp/audacity/b/test_b.wav”) works as expected.
- It seems that Audacity forwards the file name unchanged to the running instance, causing it to be resolved against the working directory of the running instance instead of the current working directory.
- This can cause Audacity to open a wrong file. When executing “audacity test_a.wav” in any directory, the file /tmp/audacity/a/test_a.wav will be opened.
There can only ever be one instance of Audacity. This is by design.
There can be multiple “projects” open at the same time, but that is multiple project windows within one instance of the Audacity program.
Entering “audacity” at the command line attempts to launch the Audacity application. However, if Audacity is already running, it brings the currently running instance of Audacity to the foreground. It does not launch a new instance, because there can only ever be one instance.
As you launched Audacity from “/tmp/audacity/a/”, the current working directory for Audacity is “/tmp/audacity/a/”.
Even though ‘you’ have changed to “/tmp/audacity/b/” in the terminal, Audacity is still running with “/tmp/audacity/a/” as its working directory, so “test_b.wav” will not be found.
The best way to open “test_b.wav” in a new project window from the command line, would be to use the absolute path (in double quotes).
You can use relative paths, but they must be relative to the directory that Audacity (the one instance that is running) was launched from.
I agree that this is a bug. Audacity does something that no user would expect or want (interpret paths relative to some arbitrary directory).
Your explanation makes sense as to why the bug exists, but it doesn’t mean it’s not a bug.
Firefox gets this right. If you say “firefox foo.html”, it will open foo.html in an existing window, but it will be the foo.html in the directory from which I ran the command.
However, if Audacity is already running, it brings the currently running instance of Audacity to the foreground. It does not launch a new instance, because there can only ever be one instance.
That’s fine; all audacity has to do is to convert the relative path to an absolute one before passing it to the running instance.
Well it’s not really an “arbitrary directory”, it’s the current working directory of the application.
Do you program (any language)?
Getting the absolute path of a command line argument is not straightforward, especially for cross-platform applications. I recall asking many years ago about command line arguments, and was told that even the one supported argument (the file name) was only provided as a convenience for developers rather than an end user feature (it is after all a “graphical” audio editor).
Using Audacity from the command line would be considered an “advanced” use, and Audacity does provide “advanced” functionality.
Audacity provides a way to open multiple files that is more flexible than a single command-line argument: LOF Files - Audacity Manual
There is now also a scripting API: Scripting - Audacity Manual
Many thanks for the insightful reply. I take it as a compliment to be considered an “advanced user”
I applied the following workaround to src/AudacityApp.cpp, line 1926: Replace
wxString param = parser->GetParam(i);
const wxString param = fileName.GetFullPath();
This works for me and I consider the issue solved.
Nice I thought there must be something like that in WxWidgets but I couldn’t find it.
I think the same approach should work for Windows and Mac, in which case I think this would be a “nice to have” enhancement. I’ll check it out.
A bit more digging revealed that this issue was the same on Windows and Linux, but not macOS. On macOS the behavior is what you described as “expected”.
Thanks for your work on this jpr. Audacity has now been updated to give the same behavior as macOS on all platforms.
Thanks jpr and steve, well done!