@Capehill It might help to clarify exactly what "name" you want to change, since programs run from the Shell are a bit odd on the Amiga:
As I recall, their actual process name is "Background CLI", but some System utilities (like my Stacker example program) will spot it's a CLI process & add the cli_CommandName name in brackets after it.
If you use the Status command, then it appears to show a list of the cli_CommandName of all CLI processes.
So which name are you seeing & where are you seeing it?
@broadblues Yes, if you assume he wants to change cli_CommandName. However, he said "rename a shell *process*". So it almost sounds like he wants to change the process name, which will be "Background CLI"...
If a program is started from shell, is it possible to give it a custom name at runtime using some library API?
The word process was never used by him, if he wants to reame the process he can't, as far as I know, he can name a subprocess started from the prgram with CreateNewProcTags() with the NP_Name tag.
Generaly the shell process is called "Shell Process" only things running in the background get a process called Background CLI
@ChrisH Huh okay, so he mentioned process in the title, not in the actual body of question, anyway whilst you were asking you were pontificating on what he might have asked, I simply answered the question, and in my follow up to you the other possibilty is covered, so I guess all bases are covered.
I was a little bit tired yesterday evening so I try to clarify. My expectation was that if I ran a program called "hello" from shell, it would have appeared with the name "hello" when I walk through the Exec list of tasks (ln_Name). But it didn't.
I tried SetCliProgramName() but as far as I can see, it doesn't affect ln_Name at least. It is always "Shell Process".
Technically there is just one task (or process) with no child tasks (or processes).
After some googling, I found a suggestion to just store the old ln_Name and restore it before exit. Seems to work but probably some kittens died in the process.
My expectation was that if I ran a program called "hello" from shell, it would have appeared with the name "hello" when I walk through the Exec list of tasks (ln_Name).
Ah, so my "process" suspicion was right...
Quote:
I tried SetCliProgramName() but as far as I can see, it doesn't affect ln_Name at least. It is always "Shell Process".
That's correct. SetCliProgramName() only affects "cli_CommandName".
I'm not aware of if it's possible to change ln_Name in a system-friendly way, but at least it's now clear what you want. Maybe someone else can answer you question...
Huh okay, so he mentioned process in the title, not in the actual body of question, anyway whilst you were asking ... what he might have asked, I simply answered the question, and in my follow up to you the other possibilty is covered, so I guess all bases are covered.
You are of course free to answer every possible variation of what he *might* have meant to ask... But personally speaking, I prefer not to waste my time on unnecessary stuff, so it seemed perfectly reasonable for me to try to check what he was asking first. Both ways of answering his question are reasonable, so I'm not quite sure why you're getting so hung-up on this.
@Capehill The content of ln_Name depends on how you start the program. Assuming your program is named "hello" then:
If started by entering "hello" in a shell: ln_Name is "Shell Process" If started by entering "run hello" in a shell: ln_Name is "Background CLI" If the program is started by Workbench: ln_Name is "hello"
It seems that using FindTask() is somewhat useless for anything but finding your own task ( FindTask(NULL) ) because the content of ln_Name is inconsistant.
Finding a process by program name is useless anyway since a user can rename a program to anything he wants. I have several programs and commands that I've renamed.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
So you have a program that wants set it's process name, and another that wants to find it on the task list?
I'm assuming that you have two programs as if you want to find you own process you ofcourse use FindTask(NULL) no need for a name.
Why do you want to do this?
If you want to make sure only one copy of the program is running (ie the second prgram is an instance of the first) you would normally do that via a named message port or similar.
It's supposed to be a top clone. Thus, it is obviously very useful to see at least the "top" task's name listed in the view, when there are more than one "Shell Process".
It's still one process that wants to have its unique name (see above), and the same process that wants to list the names of all tasks.
I will have to investigate exclusive startup. Due to how this clone works at the moment, it would be a disaster to have more than one instance running. But maybe there is a better way to sample CPU usage than poking tc_Launch/tc_Switch? I have to investigate how Hieronymus profiler works.
Anyway, the task name issue is solved. In internal data structures any invented name can be used when the current Task pointer matches the one being checked.
Also poking the ln_Name field works but it is a hack.
It's supposed to be a top clone. Thus, it is obviously very useful to see at least the "top" task's name listed in the view, when there are more than one "Shell Process".
In that case, you need to work out if the task is a process and then check it's cli name and display that.
I'm not sure of the "official" way to determine a process from a task but one way might be to call IDOS->GetProcMsgPort() and if the result is not NULL it's a process, then you can look at the CLI structure if present, remebereing that it's s a BPTR
[Edit] Perhaps it's just as simple as checking for the node type and if it's NT_PROCESS it's a process[/edit]
Then you can print the taskname and the command name together
eg
Background CLI [bldyn]
for the blender main process
Philosophicaly speaking should top show itself in the list? It doesn't seem to in the version I have here, which only shows the Process name not teh CLI command name. I'm not sure where I got it from unless it came with teh SDK?
If I run two version of "top" here I see the Shell Process for the other running just below page_sweep in CPU usage, but not the version I'm running in the list, both are using less than 1 % CPU though the WinFrame Process for the console takes about 3% on my SAM.
Joerg wrote a "top" command ~10 years ago. Today I found it from my harddrive. It lists also task switches per second and apparently the time spent inside Forbid(). This version also lists itself and support dynamically started new tasks without issues.
It handles detecting CLI/Shell commands, and correctly appends their actual name to the process's name (see the copyTask() procedure). It's written in the E language (specifically the PortablE version).