Questions/observations about start-up code in impl.c

[jphartmann]

1. -f and -r options, while basically the same, are processed differently.

a) Both test for the undocumented shut-up name "none". I propose to delete that and document setting the corresponding environment variable to null; e.g. to start hercules without any configuration file from a UNIX shell:

HERCULES_CFG= hercules

This temporarily sets the environment variable to the null string and then executes the hercules command.

What is the equivalent windoweze?

If the vote is to retain none as an option, I suggest issuing a nuisance warning rather than quietly suppressing the -f (or -r) option, which to my mind is unintuitive.

1. -l uses strtok to scan the libraries to load and supports a comma-separated list. This is undocumented and strtok inserts nulls in the environment string that messes up the command as dislayed by ps.

I suggest this be simplified to what is documented. Subsidiarily, I can use sscanf instead of strtok.

1. Is OPTION_DYNAMIC_LOAD really an option? Should it not be a requirement? When did anyone last configure without the dynamic loader?

[jphartmann]

HHC00023S Invalid/unsupported option: '-?'
HHC01414S 
HHC01407S Usage: lt-hercules [-f config-filename] [-r rcfile-name] [-d] [-b logo-filename] [-s sym=val] [-t [factor]] [-p dyn-load-dir] [[-l dynmod-to-load]...] [> logfile]

I would like to recognise the question mark and avoid message 23, but getopt substitutes ? for an unknown flag too. I assume that is OK if I figure it out.

[jphartmann]

Note that the program name is incorrect when running out of the build directory where libtool rears its ugly little head.

[ivan-w]

John,

Then do a "make install", add the run directory to your PATH and you are fine.

--Ivan

On 11/22/2015 5:25 PM, John P. Hartmann wrote:

Note that the program name is incorrect when running out of the build directory where libtool rears its ugly little head.

— Reply to this email directly or view it on GitHub https://github.com/hercules-390/hyperion/issues/86#issuecomment-158775600.

[jphartmann]

If daemon mode is specified, there is no way to terminate Hercules unless the .rc file contains a quit (or exit) command. I have changed this in two respects: 1. At the end of the .rc file, the .rc thread will drain stdin of lines and send them as panel commands. 2. If this loop terminates without having shut down Hercules and no CPUs are active, the system is then shut down.

That is, Hercules in daemon mode will respond to commands typed and it will terminate if asked to.

[jphartmann]

Here is a patch that should implement a usable -d:

daemon.txt

Does not compile on Windows. Has trouble with redirection of stdin without daemon mode.

[Fish-Git]

HERCULES_CFG= hercules

This temporarily sets the environment variable to the null string and then executes the hercules command.

What is the equivalent windoweze?

set "HERCULES_CFG=" && hercules

Note carefully the quotes. Without them the variable gets set to blanks (I think). Otherwise I think you'd need to append the && immediately after the equal sign:

set "HERCULES_CFG=&& hercules

Note: both are untested by me but I'm more confident about the first than I am the second.

But why would want to start Hercules without a configuration file? Shouldn't that remain unsupported? I can certainly understand no .rc file, but no configuration file? I'm sorry but that doesn't sound right to me.

-l uses strtok to scan the libraries to load and supports a comma-separated list. This is undocumented and strtok inserts nulls in the environment string that messes up the command as dislayed by ps. I suggest this be simplified to what is documented. Subsidiarily, I can use sscanf instead of strtok.

I hadn't ever noticed it before, but absolutely I agree.

Is OPTION_DYNAMIC_LOAD really an option? Should it not be a requirement? When did anyone last configure without the dynamic loader?

Yes, yes and unknown.

[Fish-Git]

include <previous-developers-group-comment-regarding-your-patch>

[jphartmann]

set "HERCULES_CFG=" && hercules

Did you try this in a console windows? I should think you want something like

set HERCULES_CFG="" && hercules

Either way, isn't this a permanent assignment equivalent to

set HERCULES_CFG=""
hercules

[jphartmann]

Next iteration: arg2.txt

[Fish-Git]

Did you try this in a console windows?

No.

I should think you want something like

set HERCULES_CFG="" && hercules

Nope. This is Windows remember. The above would set the variable HERCULES_CFG to the string "".

Observe:

C:\Users\Fish>set foo
Environment variable foo not defined

C:\Users\Fish>set "foo=bar"

C:\Users\Fish>set foo
foo=bar

C:\Users\Fish>set foo="bar"

C:\Users\Fish>set foo
foo="bar"

C:\Users\Fish>set foo=""

C:\Users\Fish>set foo
foo=""

C:\Users\Fish>set "foo="

C:\Users\Fish>set foo
Environment variable foo not defined

C:\Users\Fish>

Either way, isn't this a permanent assignment equivalent to

set HERCULES_CFG=""
hercules

Permanent for that command prompt session, yes. But opening another command prompt window would start with its own environment where said variable would start with its default value (or possibly not even be defined!).

To permanently change an environment variable you need to go to the Control Panel and define it there. Then all processes that are created from that point onward will have that value.

But all sets done within a given Command Prompt window ("terminal" window to you) are only temporary and only affect that session (or any process that session starts) and not any other The updated environment for that session is lost as soon as the window is closed.

[ivan-w]

Maybe should something else than environment variables should be used ?

--Ivan

On 11/25/2015 12:58 AM, Fish-Git wrote:

Did you try this in a console windows?

No.

I should think you want something like

|set HERCULES_CFG="" && hercules |

Nope. This is Windows remember. The above would set the variable |HERCULES_CFG| to the string |""|.

Observe:

|C:\Users\Fish>set foo Environment variable foo not defined C:\Users\Fish>set "foo=bar" C:\Users\Fish>set foo foo=bar C:\Users\Fish>set foo="bar" C:\Users\Fish>set foo foo="bar" C:\Users\Fish>set foo="" C:\Users\Fish>set foo foo="" C:\Users\Fish>set "foo=" C:\Users\Fish>set foo Environment variable foo not defined C:\Users\Fish> |

Either way, isn't this a permanent assignment equivalent to

|set HERCULES_CFG="" hercules |

Permanent for that command prompt /session/, yes. But opening another command prompt window would start with its own environment where said variable would start with its default value (or possibly not even be defined!).

To permanently change an environment variable you need to go to the Control Panel and define it there. Then all processes that are created from that point onward will have that value.

But all |set|s done within a given Command Prompt window ("terminal" window to you) are only temporary and only affect that session (or any process that session starts) and not any other The updated environment for that session is lost as soon as the window is closed.

— Reply to this email directly or view it on GitHub https://github.com/hercules-390/hyperion/issues/86#issuecomment-159443056.

[dasdman]

In regards to OPTION_DYNAMIC_LOAD, yes, there are cases in which it is intentionally NOT used. The primary case is in creating highly-optimized load modules where the compiler performs inlines and optimization of code between sources during linking process. This was last working around the 2010-2011 time frame, and performance wise, it does make a difference.