Autoexec fixes

[FeralChild64]

Description

• restored behavior of dosbox FOOBAR.EXE automounting current directory as drive C:
• restored behavior of skipping [autoexec] sections if directory, file, or boot image was provided on the command line, and autoexec_section from [dosbox] has value different from join
• emulator won't try to automount Z: drive from a user provided directory
• all the mount commands generated are now preceded by unmount attempts
• commented out the SHELL: Redirecting output to ... log, it is printed out much too often, also when executing some autoexecs

---

Note: The Z:\AUTOEXEC.BAT generator tries to be smart and friendly - but IMHO it often works in a way which is strange and counterintuitive:

• imagine we fave FOOBAR.BAT in the current directory; dosbox FOOBAR.BAT will generate CALL FOOBAR.BAT, but dosbox FOOBAR or dosbox "FOOBAR.BAT /switch=y" won't prefix the batch file invocation with CALL
• one of the conditions to determine whether AUTOEXEC.BAT should get an exit command at the end is the startup verbosity parameter, and it is the value auto that is handled differently
• if we have a DOOM.BAT file and DOOM directory, dosbox DOOM will try to mount the directory, but won't launch the game

I'm not using this functionality, I don't know what was the rationale behind them, so it is hard for me to propose a solution that is logical and won't upset users.

---

Related issues

#2987

Manual testing

I recomment to uncomment #define DEBUG_AUTOEXEC in src/shell/autoexec.cpp and recompile before playing with various options - this will print out the generated Z:\AUTOEXEC.BAT to the logs, making it easier to see what is actually happening.

Checklist

Please tick the items as you have addressed them. Don't remove items; leave the ones that are not applicable unchecked.

I have:

• followed the project's contributing guidelines and code of conduct.
• performed a self-review of my code.
• commented on the particularly hard-to-understand areas of my code.
• split my work into well-defined, bisectable commits, and I named my commits well.
• applied the appropriate labels (bug, enhancement, refactoring, documentation, etc.)
• checked that all my commits can be built.
• confirmed that my code does not cause performance regressions (e.g., by running the Quake benchmark).
• added unit tests where applicable to prove the correctness of my code and to avoid future regressions.
• made corresponding changes to the documentation or the website according to the documentation guidelines.
• locally verified my website or documentation changes.

[johnnovak]

Thanks, @FeralChild64.

I'm not using this functionality, I don't know what was the rationale behind them, so it is hard for me to propose a solution that is logical and won't upset users.

I think it's probably good overall that we restored this functionality, but if it's ultimately something no one in the dev team cares about and it's weird, counterintuitive, obscure, complicated, and edge case-y, maybe it's chopping block time... 😄

We'll see how this goes and how much trouble it causes down the road.

[johnnovak]

Code looks fine @FeralChild64 and I have really low interest in this feature so I trust your manual testing 😄

[weirddan455]

Did some testing.

cd /home/daniel/dos/DOOM_SE
/home/daniel/code/dosbox-staging/build/debug/dosbox DOOM.EXE

This works 👍

cd /home/daniel/code/dosbox-staging
build/debug/dosbox /home/daniel/dos/DOOM_SE/DOOM.EXE

This does not work and is a regression from 0.80.1

restored behavior of dosbox FOOBAR.EXE automounting current directory as drive C:

I believe this is the problem. Behavior should not be to mount current directory but instead mount the directory the .exe is located in.

I'm going to stay out of the argument of whether we should keep this feature in. I think @kcgen made some good points about why we should have this.

[FeralChild64]

cd /home/daniel/code/dosbox-staging
build/debug/dosbox /home/daniel/dos/DOOM_SE/DOOM.EXE

This does not work and is a regression from 0.80.1

restored behavior of dosbox FOOBAR.EXE automounting current directory as drive C:

I believe this is the problem. Behavior should not be to mount current directory but instead mount the directory the .exe is located in.

OK, I'll investigate it. Switching back to draft for now.

[FeralChild64]

@weirddan455 Should be fixed now.
@kcgen You can continue the review.

[kcgen]

Working great, @FeralChild64.
Executables with relative paths, absolute paths, and those without any path (local files) all mount and launch without issue. 👍

Baseline tests (-c, -conf, and without args) are running good too.

[kcgen]

I think everyone's reviewed the code, and with the regression fixed, it's time to merge.

[es20490446e]

Thanks for the fix, number one 🥇