When running in text mode (autoexec=telinit~3), the script is started as a sysvinit manner, as /etc/rc.d/rc4.d/S-updatemodulename, and while it is running in this manner, it cannot be killed with Ctrl-C. If I allow the system to proceed to init 3 and I log in as root or guest, then execute the same script, it can be killed with Ctrl-C.

I wasn't able to get this working properly with 'trap' or by executing a script via 'exec' instead of calling it directly. I think it does have something to do with init 4 -- If I have the script run out of /etc/rc.d/rc.S, ctrl-C will exit out of it. When I place the script anywhere in rc.M (after moving to init 4), ctrl-C fails to exit out of it.

I'm sure there is a way to force the system into init 3 instead of 4 for your custom setup, since porteus used to default to 3 (and now defaults to 4). Fanthom will know how to do this for sure...

Please take a look at our online documentation, here. Suggestions are welcome!

for the security reason "job control" is turned off while slackware/porteus is booting (you can observe that by adding "login -f root" at the end of rc.M script). that's why you cant break (ctrl+c) your script while it's running.
the only way to solve this issue is to let portues finish booting -> enable autologin -> run custom command through .bashrc or so.

all these must be achieved by editing /etc/inittab.

unfortunately agetty used in slackware does not support autologins (unlike mingetty for example) so you have to follow this HOWTO:link

/etc/login.defs part can be skipped.
please also remove 'autoexec=' cheatcode as everything is controlled by inittab.

Thank you for your reply, but this method doesn't work.
I am already using it as i mentioned in first post and the problem still exists.
For now I'm trying to boot without telinit~3.
Then my script starting and I'm able to kill it with ctrl+c, but getting error messaged about starting display messages and error from INIT:
Id "x1" respawning to fast, disabled for 5 minutes.
If just turn off this messages some way i think it will be fine.

Really?!
By doing what you just did you have opened up every users desktop to the whole wide world. (If that was the intent then this is an "undocumented feature" - in MS lingo - as opposed to a "fix".)
Here is why....
A] More as an aside; WTF is yet more bash script doing in the kernel's pipeline where there should be nothing(!!) but C, C++ code?!?! (and as you have found out yourself you actually needed a piece for inittab to function. - Correct?!) So, that already indicates that something might not be "all fixed" here.
B] So now (with this "fix") the original shell, which calls the actual process, has no chance to spawn a new one which ***will not be over ridden*** by inittab, due to the C snippet (over ride) you have happily provided.
C] This way ***anyone*** can log into an already running (and supposedly "locked") machine, switch to a fresh tty (Ctrl Alt +Fx), ***kill any process started by the original shell*** (including any Screen Savers, Screen Locks and the likes) and simply bail back out directly into the original user's already running (open) desktop. - Would this be what you had in mind??
D] Before this "fix" one could call, let say X, with "exec" and all would be well with the world because if someone tried from a new shell to reach "your (already running) desktop, when they Ctrl +C it would just kill ***their original process*** and spawn them a new shell, presenting them with a fresh log-in prompt. Now bash has no control over it, whatsoever.
E] Hence, there is no "fix" for your "fix". (At least nothing that jumps to mind or seemingly easy to implement.) But one would be thrilled hear it if you are aware of one :-)
... and as always, it's just my 2c

p.s. At any time you get the undeniable urge to "script" into the pipeline, stop and ask yourself "what could go wrong?" - Normally the correct answer is: Everything!

instead of wasting your time on writing a post which has nothing more than a rant you could just provide a better solution to the problem.
isn't it?
or maybe you dont have it?

EDIT:\\

tried your 'exec' solution and it didn't work for a simple reason:
job control is turned off while slackware is booting.
this is a security feature and the only solution (as far as i know) is to let the booting finish -> autologin -> start the process.

this way nothing is "opened to the whole wide world" (job control is still turned off during boot) and solution proposed by me is nothing different than normal booting to text mode -> logging in with 'root/toor' and starting the process manually.
the only difference is that everything is automated.

This way ***anyone*** can log into an already running (and supposedly "locked") machine, switch to a fresh tty (Ctrl Alt +Fx), ***kill any process started by the original shell*** (including any Screen Savers, Screen Locks and the likes) and simply bail back out directly into the original user's already running (open) desktop. - Would this be what you had in mind??

i think you have missed the whole issue:
desktop will never be started as booting finishes in text mode.
and this is what the OP was trying to achieve (autologin to console and start script).

and solution proposed by me is nothing different than normal booting to text mode -> logging in with 'root/toor' and starting the process manually.

You actually believe that? - and in the meantime your code-snippet is for what, ambiance?
And for those not so far in the back of the class, I did also mention "already running processes/users". - No?!
But hey, its your project, knock yourself out see if you manage to replace the entire linux kernel with just bash scripts. Seems like the improvement the whole world has been waiting for. How is it going so far?....