Help with Startup files

[Nautilus]

I'm stumped on a couple Startup file issues I'm having. WorkBench 1.3 (34.20) in WinUAE.

1)
In Shell-Startup I set the prompt like this (CLI-Startup has the same):
Prompt "%N.%S> "
but the %S part is not displaying and I don't know how to figure out why.
Sample: https://imgur.com/a/9KjZoGr

2)
Perhaps that has to do with my questions involving CLI and Shell-Seg in Startup-Sequence.

Help me understand all of this line:
Resident CLI L:Shell-Seg SYSTEM pure add

I gather what Resident does,
Looks like it loads CLI with the Shell-Seg library.
What does SYSTEM do here?
When Startup-Sequence runs I get a "pure bit not set" message. Looking at the CLI file the pure bit is not set, so that makes sense. Maybe I accidentally lost that bit and can turn it back on? Presumably it can/should be set for the CLI command? Hm, none of the commands have the pure bit set.

[daxb]

SYSTEM is an argument of Resident: https://wiki.amigaos.net/wiki/AmigaO...rence#RESIDENT

Protection bits can be changed with Protect.

[Nautilus]

Looking at a WB1.3 (34.34) .adf I see NONE of the commands in :S :System or :L have the pure bit set either.

Can anyone tell me if #2 in my original post has anything to do with #1? Current goal is just #1.

[daxb]

The disk based command path is "SYS:C". Some commands are placed in ROM. Just enter "resident system" for example to get a list. You can get a list of search paths for disk based commands when you type "path".

To get command templates: "<command> ?" e.g.: "resident ?"

[Nautilus]

When I enter "resident system" I see 3 things that are loaded: FileHandler, Restart and CLI. This is with the "Resident CLI L:Shell-Seg SYSTEM pure add" line in my Startup-Sequence commented OUT.

So, CLI is somehow resident but I'm not sure about Shell-Seg and if this has anything to do with getting %S to work.

[daxb]

I had a look at my OS1.3 WHDLoad install. L:Shell-Seg should have the pure (p) bit set. If this is not the case on your install it might be the causer of your problem. The PURE argument should overwrite a not set pure bit, if I understand it right. However, try "protect L:Shell-Seg p add" to set the pure bit, uncomment the resident line in your S-S and reboot to see if it help. With:

Resident CLI L:Shell-Seg SYSTEM pure add

CLI - is the name of the resident "module"
L:Shell-Seg - is the file that will be load.

Because the Shell-Seg is added you should get two times CLI in the "resident system" list if everything worked as expected. I don't know why Shell-Seg is added instead of replaced by default. If you want to know details about Shell/CLI you should ask Thomas Richter.

[Nautilus]

Thank you so much for the detailed help!! Changing the pure bit on Shell-Seg did the job, that and the Resident line have %S now working.

[daxb]

The question is why the pure bit wasn't set. Protection bits can be lost when you use zip as archiver or if you depack stuff on a PC system. Non Amiga filesystems (e.g. FAT) usually don't support Amiga protection bits and file comments. So using LHA/LZX/... and depack archives on Amiga side is a good idea.

[Nautilus]

Yea, but no real way to know for sure. I don't know if it was a mistake with the original copy run, or if it happened later. Open box with original floppies (in visually pristine condition) was acquired from ebay then put in an Amiga where the adf's were made.

On another topic, the 's' bit. I saw that while I was looking at protect, and none of the files in /s had the script bit set so I did that, but then each time I ED a file it loses the 's' bit. However, it seems unimportant since they run fine without it?

[Hewitson]

The S or Script bit basically makes the script behave like an executable file (ie you can run it without using EXECUTE).

Certainly not useful applying it to anything in S:

[Nautilus]

Originally Posted by Hewitson

The S or Script bit basically makes the script behave like an executable file (ie you can run it without using EXECUTE).

Certainly not useful applying it to anything in S:

Ah, thank you for the clarification!

[Hewitson]

Originally Posted by Nautilus

Ah, thank you for the clarification!

Happy to help!

[daxb]

Originally Posted by Nautilus

On another topic, the 's' bit. I saw that while I was looking at protect, and none of the files in /s had the script bit set so I did that, but then each time I ED a file it loses the 's' bit. However, it seems unimportant since they run fine without it?

I noticed this too and seems to be an editor or program x problem. IMHO the best/easiest thing you can do is to ignore the s bit because you don't always know or can make sure that the s bit isn't lost. Instead just use "execute <scriptfile>" that will always work.

[Nautilus]

Thanks again daxb! If it's not too much trouble would you take a look at my Startup-Sequence? Workbench 1.3 (34.20). Trying to keep it simple, but any constructive criticism is appreciated. A few things I wonder right off the bat...

1) SetPatch should be the first command, but does that mean nothing, not even a comment before it? I'm having a dejavu feeling that there should be nothing before it.

2) Do the PATH or (commented out) STACK settings only last for the duration of the script? My guess is No and Yes, respectively.

3) Any other problems stand out?

;;; My Startup-Sequence

SetPatch >NIL: ; Patch system functions

Path RAM: c: SYS:system s: add ; Add directories to path

;;; I don't think this matters much (default is 10?)
; AddBuffers df0: 8 ; Buffer blocks for drive

Echo ""
Echo "      ==  Hello World  =="
Echo ""

;;; Comment out this line for 512K systems
FastMemFirst ; Move C00000 memory to last in list

;;; Don't think this should execute by default
; BindDrivers  ; For printers, etc?

;;; If this command is available, it's handy for boot-time info
;Version

;;; Set Stack to 12288 for 512K Startup, 20480 for >512K
;;; 2020: I'm not sure this matters at all, it's only for the duration
;;; of Startup-Sequence? If Startup fails, uncomment this & re-test.
;Stack 20480

;;; Load system date & time from real time clock
;;; A1000 users should set the date & time manually
SetClock load

;;; Mount the new console (used by Shell)
Mount NEWCON:

;;; Make sure CLI includes Shell-Seg
Resident CLI L:Shell-Seg SYSTEM pure add ; Activate Shell

;;; Not enough room on Disk1 for command files to do StartupII
;Failat 11
;run execute s:StartupII
;wait >NIL: 5 mins ; Wait for StartupII to complete (will signal when done)


;;; Change to the directory with the executables
Cd MainDirectory

;;; Set the environment variables by 3 Assign'ments or First!
;;; Pick one method to use
;Assign MyPIC: Disk1:Data/pictures    ; The output directory
;Assign MyDAT: Disk1:Data             ; The data directory
;Assign MyBIN: Disk1:Bin              ; The app's directory
First! ; GUI for setting the environment variables
       ; You must click ASSIGN to make the Assign's, RETAIN means cancel.
       ; Unfortunately it does not inherit from the current Assignments,
       ; the default settings are baked into the app.

;;; Pick one method to start program Main (512K or >512K)
;RunBack Main WB  ; For 512K systems (load WB after exiting Main)
LoadWB delay     ; For >512K systems  - We have memory space to
RunBack Main     ; For >512K systems  - load both WB and Main

Endcli >NIL:

[daxb]

1: Sorry, I don't understand what do you mean. Usually it is a good thing to run SetPatch.

2: As far as I know stack leaves to child processes. Newcli or newshell will get the values of the mother process. Path too but maybe it is a global switch. You should be able to test it yourself. After boot open a shell and type "path" and "stack" to verify the values.

3: I don't know but looks good IMHO. RunBack I don't know. Can't you add enough memory to your WinUAE system, so that you don't need to care about low memory issues?

[Nautilus]

1) My apologies. I was asking about the comment and blank line before SetPatch. I thought I remembered something about that being a no-no, but when testing with a newly opened shell, typing SetPatch says "Patches already installed" so I think that answers that Q.

2) FYI: After testing it appears that if I type "newshell" in shell, the new shell will inherit both settings. However if I close out all shell's and open a new one from the GUI, they are both back to default. Interestingly, when "path" is set in Startup-Sequence it seems to become the default... every new shell will inherit it. This is not true for "stack".

3) I'm pretty much re-mastering the original release with a simplified Startup to make it easier to understand. This is as the original 2-floppy set. If the adf's are converted back to real floppies it should still run on a 512K single-floppy system (with the edits noted in Startup-Sequence). If I get the time I'll do a second HD file organization of both floppies which will be more suited to an emulator or actual HD system.

I really appreciate the help you have given me in this thread. Thank you!

[daxb]

I think comments behave equal on all systems. I.e. they are ignored while parsing a text file. Same should go for blank lines. You could add thousand of blank and/or comment lines somewhere in your S-S or other script and it will work. Of course that wouldn't make sense.

At the end of S-S there is "Endcli >NIL:" what will close the shell process. Because stack is set/assigned for the current process it will be lost with Endcli. Path seems to be process independent.

[Nautilus]

Originally Posted by daxb

I think comments behave equal on all systems. I.e. they are ignored while parsing a text file. Same should go for blank lines.

Oh I know that my Q about this is odd. I've used comments since before the Amiga existed but I still can't shake the feeling that I had an issue with SetPatch not being at the very top of the file in the 80's. It's working fine now with comment and blank line, issue resolved, just trying to explain myself.

Originally Posted by daxb

At the end of S-S there is "Endcli >NIL:" what will close the shell process. Because stack is set/assigned for the current process it will be lost with Endcli. Path seems to be process independent.

To clarify my test results: When Path is added to in Startup-Sequence it seems to be process independent, but ONLY when added in Startup-Sequence. If I open a shell, add to the path, close the shell, and open a new one, the addition is gone.

[Thomas Richter]

Originally Posted by Nautilus

To clarify my test results: When Path is added to in Startup-Sequence it seems to be process independent, but ONLY when added in Startup-Sequence. If I open a shell, add to the path, close the shell, and open a new one, the addition is gone.

The path is separate for each process, though the workbench inherits the path and the shell variables from the initial CLI and the CLI program inherits it from the workbench. Also, newcli inherits the path and variables from its creator.

[Nautilus]

Hi Thomas, thanks for your clarification. I was thinking about starting a new thread about the stack command, but maybe it works here.

I'm trying to remember why I set a big stack size in Startup-Sequence in 1989. Roughly 12k for 512K systems and 20k for >512K systems. I've been running my programs in WinUAE lately with stack at default (4000?).

I don't remember why stack size matters to a Shell user, maybe it doesn't and I made a mistake back then. I'd guess that I set an internal stack size for the apps when I compiled them, and I'm not sure if the two meanings of stack relate or inherit. New at this again after 30 years.