Hello g00r00!

Came to think of it -- is there any reason why Mystic on Windows (according to whatsnew.txt) doesn't sink stdout of archiver commands to NUL (> NUL), but rather just stderr (2> NUL)? That is, why it performs "2> NUL" instead of "> NUL 2>&1"?

Since -- isn't it so that any output from these commands will be shown to the user (possibly confusing the user and garbling the "screen" with a lot of technical mumbo-jumbo)? So one wants to avoid any such output to the user?

Granted that sinking stdout to /dev/null or NUL in general *does* create a problem for the archive View Cmd -- as the redirection to an output file will break... But this is easy to "fix" with a simple work-around for the View Cmd (e.g. for 7Z and ARJ):

Linux: command "%1" >> "%3%2" 2> /dev/null; exit $?
Windows: command "%1" >> "%3%2" 2> NUL || exit 1

The last one is a little "sloppy" as it doesn't capture the exact exit code on error. I believe it might be possible to capture the actual exit code also on Windows, but one would have to use delayed expansion, but I'm no expert in that area.

Just curious (as this is a difference for "external" archive viewing between Mystic on Linux and Windows).

Best regards
Bj”rn

--- Mystic BBS v1.12 A47 2021/08/08 (Linux/64)
* Origin: Star Collision BBS, Uppsala, Sweden (2:201/137)

Since -- isn't it so that any output from these commands will be shown
to the user (possibly confusing the user and garbling the "screen" with
a lot of technical mumbo-jumbo)? So one wants to avoid any such output
to the user?

In Windows it does not redirect the console through a telnet connection like it does in Unix-based systems, so doing the NUL is just to stop error messages from an archive leak through to the local screen when doing local mode logins and when MUTIL is performing archive related functions.

In other words, if a bunch of archive error messages are leaking into the display when MUTIL is doing its GUI updates, it would cause the status screen to appear garbled.

... A Mystic asking for a hot-dog: "Make me one with everything"

--- Mystic BBS v1.12 A47 2021/08/08 (Windows/64)
* Origin: Sector 7 * Mystic WHQ (1:129/215)

Hello again g00r00!

I've been thinking some more. Won't push this much further :-D, but:

Just curious (as this is a difference for "external" archive viewing between Mystic on Linux and Windows).

The "best" thing would perhaps be to append (internally, inside Mystic):

Windows: > NUL 2>&1
Linux: > /dev/null 2>&1

...for Pack Cmd and Unpack Cmd, and "only":

Windows: 2> NUL
Linux: 2> /dev/null

...for View Cmd.

Then the "stock" View Cmds shipped with Mystic (ARJ is missing one, though) would continue to work right out of the box without any "trickery", and the platforms would behave the same with regard to stderr/stdout of the archiver commands.

Best regards
Bj”rn

--- Mystic BBS v1.12 A47 2021/08/08 (Linux/64)
* Origin: Star Collision BBS, Uppsala, Sweden (2:201/137)

I've been thinking some more. Won't push this much further :-D, but:

Just curious (as this is a difference for "external" archive viewing between Mystic on Linux and Windows).

The "best" thing would perhaps be to append (internally, inside Mystic):

Windows: > NUL 2>&1
Linux: > /dev/null 2>&1

Mystic's local console API in Windows already takes over STDIN and STDOUT.

... What hair color do they put on the driver's licenses of bald men?

--- Mystic BBS v1.12 A47 2021/08/08 (Windows/64)
* Origin: Sector 7 * Mystic WHQ (1:129/215)

Hello g00r00!

On 09 Aug 2021, g00r00 said the following...

In Windows it does not redirect the console through a telnet connection like it does in Unix-based systems, so doing the NUL is just to stop
error messages from an archive leak through to the local screen when
doing local mode logins and when MUTIL is performing archive related functions.

Thanks for the clarification!

Best regards
Bj”rn

--- Mystic BBS v1.12 A47 2021/08/08 (Linux/64)
* Origin: Star Collision BBS, Uppsala, Sweden (2:201/137)

Hello g00r00!

Thank you for your reply!

On 09 Aug 2021, g00r00 said the following...

Windows: > NUL 2>&1
Linux: > /dev/null 2>&1

Mystic's local console API in Windows already takes over STDIN and
STDOUT.

OK, but what happens to "external" archive viewers (View Cmd) on Windows then?

Won't their output be eaten up by the console API, resulting in (seemingly) no contents inside those archives?

That's what currently happens for Linux, and the reason for needing a construct like >> "%3%2" 2> /dev/null; exit $? at the end of the View Cmd on Linux. Easy, but unnecessary, should Mystic instead only "eat" stderr of the View Cmd on Linux. :)

Now, please don't get me wrong -- I think the job you've put into the archiver stuff lately is marvelous, including the fix for the redirections, and I appreciate it all very much! Just thinking that View Cmds would be easier to construct if stdout wasn't eaten up (for View Cmds, only).

As always, thank you,

Best regards
Bj”rn

--- Mystic BBS v1.12 A47 2021/08/08 (Linux/64)
* Origin: Star Collision BBS, Uppsala, Sweden (2:201/137)

That's what currently happens for Linux, and the reason for needing a construct like >> "%3%2" 2> /dev/null; exit $? at the end of the View
Cmd on Linux. Easy, but unnecessary, should Mystic instead only "eat" stderr of the View Cmd on Linux. :)

The intention here is to block STDOUT because redirecting raw output of STDOUT from an archive utility was something I considered a security risk. It will likely expose all of the directory structure of your system which makes it easier to exploit (if one were to exist).

The external view command is intended to populate the archive data into the temporary display file and then Mystic displays that file. How that data gets into the file is not up to Mystic, its up to whatever program the view command executes. That is the desired implementation of external viewer support.

(There is also an unfinished scripted view extension that works with the ANSI viewer to allow external archivers to use the full ANSI viewer functionality. I need to get that done one of these days)

I could change it in Linux to only suppress STDERR just for view but then when someone does set up an archive viewer in the intended way, Mystic is going to show its output (by default) which would be undesired and potentially unsecure.
Mystic is trying to err on th side of security but it still allows you to do both a direct redirection like you are doing too - it just defaults to being conservative in this situation and makes you work a little more to do a STDOUT redirect.

... WOMAN.ZIP - Great program but no documentation

--- Mystic BBS v1.12 A47 2021/08/08 (Windows/64)
* Origin: Sector 7 * Mystic WHQ (1:129/215)

Hello g00r00!

Thank you for your reply!

On 09 Aug 2021, g00r00 said the following...

The intention here is to block STDOUT because redirecting raw output of STDOUT from an archive utility was something I considered a security risk. It will likely expose all of the directory structure of your system which makes it easier to exploit (if one were to exist).

Yes, you're probably right -- it is more secure to leave it the way it is. Even if this (for "conventional" archivers, which don't usually appear to have support for writing their output to a file on their own) means an extra blurb at the end of the View Cmd command line.

Thanks for the clarification!

Best regards
Bj”rn

--- Mystic BBS v1.12 A47 2021/08/08 (Linux/64)
* Origin: Star Collision BBS, Uppsala, Sweden (2:201/137)