Is C:Which buggy?

8.Workbench:> which libs: all
Workbench:Libs
8.Workbench:>

C:Assign shows SYS:Libs and MUI:Libs/

Is it also normal for "Assign Libs:" to get rid of the Libs: assign?

Also, a couple of other questions.

On OS3 I believe I could remove an assign with "Assign place: remove", but now it wants the location of the place as well.

The other question, if I don't have the SDK startup in user-startup, but in a shell I type Execute SDK:S/SDK-Startup, then the SDK will only work in that shell window. Once I upon up another window, it seems all assigns and things are lost. Is it something in SDK-Startup that makes it local? I haven't looked.

@MickJT

The 'which' command is only for finding an executable program in the current path, not for what you want here.

To view all of an assign, you can use 'assign libs: exists' or similar. See this and other fine usage information in your sys:documentation/c/assign.doc

Yes it is normal for an assign command with no target to delete the assignment. It is treated as "assign libs: to nothing"

Because assignments are a _list_ of paths to search, when you REMOVE you need to specify which path in the list you want removed.

The SDK startup scripts contain assigns, paths, and env var settings. Some of those are system-wide changes and some are for the shell only. So if you run it in one shell, that shell and others opened from it are the only places it is fully active. If it's done in user-startup, that runs in the startup task before it launches 'LoadWB', which means the Workbench inherits all the changes from it, which also means everything else like shells launched later also inherit it all.


Scott Woodall

@MickJT

Quote:
Use Assign libs: exists instead. I guess Which command is targeted for DOS commands and not paths/assigns.

Quote:
In your example of Libs: you can remove MUI:Libs with Assign libs: MUI:Libs REMOVE without losing sys:Libs. On classic system you lost both assigns with REMOVE and had to put sys:Libs back afterwards. (That feature exists for multi assigns.)

Quote:
I think Shell's are local and not global environments nowadays. (That annoyed me a little bit in the beginning but I guess there's a locigal reason for how they work.) Somebody else have to explain better.

(Edit: swoodall?did beat me to it.)