Amiga.org
Amiga computer related discussion => Amiga Software Issues and Discussion => Topic started by: powrslave on February 03, 2017, 06:03:02 AM
-
I made a script into an executable which works but the window cannot be button or minimized.
-
Is NIL what you're asking about? (ie. Not wanting CLI window to display the script contents when run)
-
i'd like to see the contents.
Similar to if I open cli and then wirelessmanager prism2.device so I make sure it connects then I can click on the little square and it turns into a script icon on desktop.
Just tired of typing it when I want to connect. (don't want it in startup)
-
Seem to recall these two as offering some utlity, but I think neither is 100% compatible with everything, and may be very ancient.
http://aminet.net/package/util/wb/CLITool
Good for running program that you normally have to use a CLI for, by double clicking an icon instead.
http://aminet.net/search?query=IconJ
Funkier version of IconX with reconfigurable output. IconX just displays an "Out of Order notice - noob hack going on in background, look away" blank display.
I do seem to recall IconJ being OK with later AmigaDOS releases up to 3.1 at least, but like I say, they are both pretty creaky.
-
I made a script into an executable which works but the window cannot be button or minimized.
Have you set the WINDOW tooltypes for IconX?
WINDOWS=CON:0/50//80/IconX/AUTO/WAIT/CLOSE
Install KingCON (http://aminet.net/search?query=KingCON_1.3.lha) and you will have a minimize option.
-
I made a script into an executable which works but the window cannot be button or minimized.
That is only a matter of the WINDOW specification. Add to the end of the window path a "/AUTO/CLOSE/WAIT", and the window will only pop open if the command has something to print, will stay on the screen, and will have a close button.
I.e., something like
WINDOW=CON:0/0/640/100/My Title/AUTO/CLOSE/WAIT
will do the job.
-
Install KingCON (http://aminet.net/search?query=KingCON_1.3.lha) and you will have a minimize option.
Install ViNCEd and you will have much more. Comes with 3.9 anyhow. Also understands AUTO/CLOSE/WAIT, and will have an iconify button that works.
-
What is the advantage of using project icon type with IconX as default tool vs. using tool icon type, setting S flag and set CLI as tooltype (or "Start from Shell" in 3.9 info window)?
-
I think the main reason people prefer KingCON over ViNCEd is the complexity of ViNCEd, it is rather daunting, heck, even spelling it right is TRicKy :) It has so many features that one can really wonder what kind of situations one would have need for it all. And yet, it does not have tabs (which everyone wants), and it struggles if used as terminal emulator.
-
What is the advantage of using project icon type with IconX as default tool vs. using tool icon type, setting S flag and set CLI as tooltype (or "Start from Shell" in 3.9 info window)?
The S flag can easily be lost when you copy the file to another location using the wrong options. For example the Copy CLI command will remove the flag if you forget to say CLONE.
-
I think the main reason people prefer KingCON over ViNCEd is the complexity of ViNCEd, it is rather daunting, heck, even spelling it right is TRicKy :)
I wonder what the problem with the default configuration is. Just keep it, you're fine.
It has so many features that one can really wonder what kind of situations one would have need for it all. And yet, it does not have tabs (which everyone wants)
Does Kingkong have Tabs? I guess not. Adding Tabs would be another project, but not right now please. It has virtual consoles and screens, though.
and it struggles if used as terminal emulator.
Huh, what? Unlike all the other terminals, ViNCEd includes a VT100 and VT220 emulation, and not only CBMs own interpretation of the CSI sequences (which is really quite a bit off). Actually, I used ViNCEd quite a while as ssh terminal to run emacs over a dial-in connection at our university.
-
The S flag can easily be lost when you copy the file to another location using the wrong options. For example the Copy CLI command will remove the flag if you forget to say CLONE.
Yeah, but that is really a "meta problem", and in my eyes a flaw with the copy command, I always use clone and cannot fathom why that is not default. :hammer:
I was more curious in direct benefits/caveats with using one or the other.
-
I wonder what the problem with the default configuration is. Just keep it, you're fine.
Sure - but it is a rather intrusive and... in lack of better word, "bloated" option when all you want is iconify and tab completion.
Does Kingkong have Tabs? I guess not. Adding Tabs would be another project, but not right now please. It has virtual consoles and screens, though.
Yes, and I suspect most people do not know it is there and certainly not how to set it up and use it, as I said, the configuration of ViNCEd is quite daunting. KingCON also does not have tabs, but the handler is half the size of vnc.library, and can even be put in kickstart and work when booting without startup-sequence (Yes, I know... copied to RAM before execution, still useful though.)
Huh, what? Unlike all the other terminals, ViNCEd includes a VT100 and VT220 emulation, and not only CBMs own interpretation of the CSI sequences (which is really quite a bit off).
Well, the world has moved on, vt220 is not exactly the benchmark for a good terminal anymore. ViNCEd has ANSI terminal with colours, which is nice, but 16 colours ANSI terminal is also kinda "old school" in these days of true colour xterm and consoles. There is option for tmux to deal with 256-colour terminal, but not for only 16 colours, for example. In my experience, both Term and AmTelnet (that is, the terminal MUI class) are better choices for simple terminal emulation, and it always helps to use GNU screen in the other end, less need for ctrl+L frenzy. And, then there is the question of charset handling.
Actually, I used ViNCEd quite a while as ssh terminal to run emacs over a dial-in connection at our university.
That may be why. emacs lives in its own "retro reality" and (like vt220), should not be the benchmark for whether a terminal emulation works or not. But we are touching the main topic here - why should the console handler on the Amiga even have terminal emulation at all? :)
Anyways, I do think ViNCEd is awesome, but I also see why people rather use KingCON (Kingkong is something else). It would be nice with a new console handler that implements the basics like KingCON does, but in a more system friendly way. If someone with the know-how could make a video tutorial for all the stuff one can accomplish with ViNCEd, I would love watching and learning :)
-
Yeah, but that is really a "meta problem", and in my eyes a flaw with the copy command, I always use clone and cannot fathom why that is not default. :hammer:
It's not only copy. If you use ZIP or TAR or any other non-Amiga archiver to transport the files to somewhere else, those non-standard flags get lost. Even with LhA flags are lost if you don't set the right options.
The same happens if you copy the file to a non-Amiga file system like FAT. CF0 comes to mind.
I was more curious in direct benefits/caveats with using one or the other.
The IconX thing also works on Kick 1.3.
-
OK, since I only get answers that for me are irrelevant and not really what I am asking about, I assume then that there is no difference between using IconX and setting S bit and tooltype CLI :)
I could imagine that IconX for example could read more tooltypes, there are IconX "clones" that can do a lot more.
-
OK, since I only get answers that for me are irrelevant and not really what I am asking about, I assume then that there is no difference between using IconX and setting S bit and tooltype CLI :)
I could imagine that IconX for example could read more tooltypes, there are IconX "clones" that can do a lot more.
I don't know how you would set shell size and title without IconX... with CLI you just get a shell that ignores S:shell-startup as far as I can see (or have I missed something).
With IconX you don't have to confirm the action after the double click on the icon.
-
Sure - but it is a rather intrusive and... in lack of better word, "bloated" option when all you want is iconify and tab completion.
If this is all you want, why do you then look into the preferences at all? I'm sorry, I do not get this argument. If you don't need an option, don't touch it. It's just sitting there to be used in case, that's all.
Yes, and I suspect most people do not know it is there and certainly not how to set it up and use it, as I said, the configuration of ViNCEd is quite daunting.
You use the installer. Isn't that obvious? It will install the default configuration which is what most people will likely be happy about.
KingCON also does not have tabs, but the handler is half the size of vnc.library, and can even be put in kickstart and work when booting without startup-sequence (Yes, I know... copied to RAM before execution, still useful though.)
Putting "something in Kickstart" is not a recommended option for third party components anyhow. Actually, nothing but the absolute minimum on components should go there. Did you say "bloat?" There you go.
Well, the world has moved on, vt220 is not exactly the benchmark for a good terminal anymore.
And the benchmark is? If you look into the Linux world, the terminals there all support not much more than vt220, in certain variants. xterm has a couple of extras (ViNCEd supports them), and mrxvt, too. Then we have gterm, ... you name it. There is not much more.
ViNCEd has ANSI terminal with colours, which is nice, but 16 colours ANSI terminal is also kinda "old school" in these days of true colour xterm and consoles.
Actually, if you look at xterm, it supports... 16 colors. Obviously, because that is all ANSI CSI sequences can do. I do not know about xterm, but ViNCEd allows you to change these colors, not only at the preferences, but also by CSI sequences. Search for "CSI V" in the fine manual. This is, of course, a non-standard extension because VT220 has nothing to say about true color terminals.
There is option for tmux to deal with 256-colour terminal, but not for only 16 colours, for example.
Hardly an ANSI terminal then.
In my experience, both Term and AmTelnet (that is, the terminal MUI class) are better choices for simple terminal emulation, and it always helps to use GNU screen in the other end, less need for ctrl+L frenzy. And, then there is the question of charset handling.
The Amiga charset has ever been ISO-Latin-1. Changing that is a daunting task simply because the whole rendering engine, graphics upwards, only supports 256 glyphs in a character set.
That may be why. emacs lives in its own "retro reality" and (like vt220), should not be the benchmark for whether a terminal emulation works or not. But we are touching the main topic here - why should the console handler on the Amiga even have terminal emulation at all? :)
Because otherwise tools like the screen editor "ed" would not work? The choice to include a terminal was made at Tripos terms, where the user frontend of choice was (still) the terminal. Once this was set, it became necessary to include a "terminal emulation" in the system, which is what CON: does, actually in the given implementation as a thin interface around console (which is non-tripos, but tripos had something similar).
Anyways, I do think ViNCEd is awesome, but I also see why people rather use KingCON (Kingkong is something else). It would be nice with a new console handler that implements the basics like KingCON does, but in a more system friendly way. If someone with the know-how could make a video tutorial for all the stuff one can accomplish with ViNCEd, I would love watching and learning :)
The problem here is that you confuse a bit the role of the console.device (which is one thing) with that of the console handler (CON:) which is another thing. Kingkong just hacks up the console.device, probably causing problems should it ever be upgraded. CON: is a thin layer around console. So was Newcon. ViNCEd is a self-contained handler, it does not (really) use the console.device at all.
What *should* really be done is to first replace the console.device (which is a daunting task, because it is all assembly, same problem as ViNCEd), then create a Boopsi wrapper around this, to have a clean intuition layer for a console (also helpful in a lot of other situations), and then create a dos.library wrapper around that again (CON:), and finally integrate functionality in the shell that belongs there (Tab expansion is a shell feature, not a console feature).
However, that is a major task, requires a major restructuring of the Os, and completely out of reach with the available workforce.
How to use ViNCEd? Do you really need a video tutorial how to run the installer? That's really all, nothing more needed. Don't make things more complicated than they are.
-
I could imagine that IconX for example could read more tooltypes, there are IconX "clones" that can do a lot more.
Indeed, after playing around with it some more, IconX allows tooltypes that are otherwise ignored, I see WINDOW, STACK, USERSHELL, WAIT and DELAY. When launched using just S-bit, the tooltypes CLI and DONOTWAIT are used, and I suspect STACK too.
-
If this is all you want, why do you then look into the preferences at all? I'm sorry, I do not get this argument. If you don't need an option, don't touch it. It's just sitting there to be used in case, that's all.
It's like getting a 7 course meal when all you wanted was a cup of coffee.
You use the installer. Isn't that obvious? It will install the default configuration which is what most people will likely be happy about.
If "most people" were happy with this, "most people" would not be using KingCON. However, most people are using KingCON, so I presume "most people" are not so happy with VNC. Why is that? Well, I have mentioned quite a few reasons.
Putting "something in Kickstart" is not a recommended option for third party components anyhow. Actually, nothing but the absolute minimum on components should go there. Did you say "bloat?" There you go.[/QUTE]
This is about functionality - by putting KingCON in kickstart, tab completion and various other features are there also when booting without startup-sequence, or when booting to other filesystems (floppies, games etc).
Is there any way to have ViNCEd available like this? I think not.
And the benchmark is? If you look into the Linux world, the terminals there all support not much more than vt220, in certain variants. xterm has a couple of extras (ViNCEd supports them), and mrxvt, too. Then we have gterm, ... you name it. There is not much more.
mrxvt is ancient software now and gterm is also not really a good terminal :)
Anyways, there is much more. xterm also does vt420 and has its own extensions, such as the color255. If you look at modern implementations such as iTerm on and others for Linux and BSD etc, that can also output graphics directly to the terminal window.
Actually, if you look at xterm, it supports... 16 colors. Obviously, because that is all ANSI CSI sequences can do. I do not know about xterm, but ViNCEd allows you to change these colors, not only at the preferences, but also by CSI sequences. Search for "CSI V" in the fine manual. This is, of course, a non-standard extension because VT220 has nothing to say about true color terminals.
http://www.mudpedia.org/mediawiki/index.php/Xterm_256_colors
Hardly an ANSI terminal then.
As I keep saying - the world moves on!
The Amiga charset has ever been ISO-Latin-1. Changing that is a daunting task simply because the whole rendering engine, graphics upwards, only supports 256 glyphs in a character set.
It has already been done. MorphOS's terminal MUI class does this.
Because otherwise tools like the screen editor "ed" would not work?
Let me just shortly counter this by saying "most users do not use ed" ;)
The choice to include a terminal was made at Tripos terms, where the user frontend of choice was (still) the terminal. Once this was set, it became necessary to include a "terminal emulation" in the system, which is what CON: does, actually in the given implementation as a thin interface around console (which is non-tripos, but tripos had something similar).
Yes - but there is a difference between "native terminal" and fully emulating ANSI vt220, vt420, xterm etc.
The problem here is that you confuse a bit the role of the console.device (which is one thing) with that of the console handler (CON:) which is another thing. Kingkong just hacks up the console.device, probably causing problems should it ever be upgraded. CON: is a thin layer around console. So was Newcon. ViNCEd is a self-contained handler, it does not (really) use the console.device at all.
Now I understand you are writing "Kingkong" just to mock it. How quaint.
"Most users" (and this time I include myself) do not really care much about _how_ the console/terminal/shell window is implemented. "Most users" do not even use shell much (though some of us do).
How to use ViNCEd? Do you really need a video tutorial how to run the installer? That's really all, nothing more needed.
Tutorial about how to use more advanced features to empower users. Isn't that what software is all about?
Don't make things more complicated than they are.
I have a feeling that this is exactly why ViNCEd is not so popular :)
Features wanted by "most users" for the console, easily accessible from a menu..
* iconify
* jump screen
* tabs
* switch to full screen mode and back
* vertical and horisontal split terminal
* prefs to configure profiles with colours, programs to start etc.
And yes - the shell should provide the tab completion.
Anyways - all these are great reasons to rather use AROS :laughing:
-
Indeed, after playing around with it some more, IconX allows tooltypes that are otherwise ignored, I see WINDOW, STACK, USERSHELL, WAIT and DELAY. When launched using just S-bit, the tooltypes CLI and DONOTWAIT are used, and I suspect STACK too.
STACK is not a tooltype, but a fixed entry in the DiskObject. Otherwise, the differences between SYS:System/CLI, SYS:C/IconX and the workbench start are indeed minor. All of them end up in SystemTagList() to run the shell script, with one subtle difference that CLI and IconX first create a dummy CLI structure from the template in the workbench task. The workbench itself does not need to, it already has a CLI that is cloned by SystemTagList().
There are various re-implementations of IconX that are considerably more powerful than IconX. CLICon, for example, also allows arguments by selecting the "script icon" along with another icon "as argument".
-
STACK is not a tooltype, but a fixed entry in the DiskObject. Otherwise, the differences between SYS:System/CLI, SYS:C/IconX and the workbench start are indeed minor. All of them end up in SystemTagList() to run the shell script, with one subtle difference that CLI and IconX first create a dummy CLI structure from the template in the workbench task. The workbench itself does not need to, it already has a CLI that is cloned by SystemTagList().
There are various re-implementations of IconX that are considerably more powerful than IconX. CLICon, for example, also allows arguments by selecting the "script icon" along with another icon "as argument".
Do you know if there's a way to set the size of the window if you use the S-bit and start the script as a tool with "CLI" as tooltype?
I thought I might be able to just ass a line in the script execute script2 >CON:0/0/640/100/Titel/WAIT/CLOSE but that only create a new shell on top of the old one and the scripts continues with it's outputs on the first window.
-
Do you know if there's a way to set the size of the window if you use the S-bit and start the script as a tool with "CLI" as tooltype?
There is none. The workbench computes a suitable size from the font size and the size of the workbench screen. It's always an approximate 80x16 console window
I thought I might be able to just ass a line in the script execute script2 >CON:0/0/640/100/Titel/WAIT/CLOSE but that only create a new shell on top of the old one and the scripts continues with it's outputs on the first window.
Correct. If you need this, use CLICon or IconX. The former allows many more options.
-
It's like getting a 7 course meal when all you wanted was a cup of coffee.
If the 7 course meal is the same price as the cup of coffee, what would I pick?
This is about functionality - by putting KingCON in kickstart, tab completion and various other features are there also when booting without startup-sequence, or when booting to other filesystems (floppies, games etc).
Is there any way to have ViNCEd available like this? I think not.
No, there is not, and even if there would, it's not supposed to be a ROM component. It's your friendly shell, not the boot shell which you barely see anyhow. That's not the envisioned use case.
Anyways, there is much more. xterm also does vt420 and has its own extensions, such as the color255. If you look at modern implementations such as iTerm on and others for Linux and BSD etc, that can also output graphics directly to the terminal window.
And xterm has a textronics (sp?) emulation in it. (-: It still doesn't make this a very popular feature. If you want truecolor support in ViNCEd - it's all there, 24 bit colors.
Anyhow, at some point one has to draw a line between "useful" and "useless", and I don't see much use for 256 colors in a console. Colored text - yes, useful for highlighting. More than a handfull of colors? No, not at all. A console is not a paiting program, and neither a plotting program (even though xterm actually is).
It has already been done. MorphOS's terminal MUI class does this.
That's good for them. Though again, if you need a UTF-8 console, you're probably better of with your average Linux or Windows machine. On an Os that does not have UTF fonts, nor a graphics system that supports them, this sounds as useful as having an 8-channel Dolby surround sound stereo in a Beetle.
Let me just shortly counter this by saying "most users do not use ed" ;)
Likely, it's a terrible editor. Though you asked "why does the system need a terminal emulator", and the answer is "because there was historically need for a terminal". If you would want to re-invent the machine, I wouldn't probably start from BCPL or Tripos either, but that's how it is. Besides, it's not really such a bad choice either given that even modern systems come with a terminal emulation (as in: Windows, Linux and even MacOs).
Yes - but there is a difference between "native terminal" and fully emulating ANSI vt220, vt420, xterm etc.
Actually, it's not really that much of a difference. Emulation of vt220 was quite useful back then, IOW, I did have a use case for that. Unfortunately, there is no working ssh implementation left, so this use case went away. It was neither very hard to add, really.
"Most users" (and this time I include myself) do not really care much about _how_ the console/terminal/shell window is implemented. "Most users" do not even use shell much (though some of us do).
Certainly. Though, I do. It seems silly to push consoles around (which I even do on my Linux machines), but I'm much faster with the keyboard than the mouse. Ten finger typing. Again "I have a use case for the shell".
Tutorial about how to use more advanced features to empower users. Isn't that what software is all about?
Oh, it is, but there is a difference between "helping users" and "spoon feeding". I do my very best to supply answers to every possible question. There is a structured manual, and there is a setup-system with an online-help system, and an installer. That's even much more than you get with most average software. A video - how would you even play this on a 68K system with at most 50Mhz? C'mon, you're asking really a bit much here.
Features wanted by "most users" for the console, easily accessible from a menu..
* iconify
* jump screen
* tabs
* switch to full screen mode and back
That's all there.
* vertical and horisontal split terminal
This is not there. Tabs (not in the sense of tab expansion) would be nice. "Screens" in the sense of the Linux program of the same name are possible (the necessary CSI sequences for that are implemented, IIRC, the 3.9 "more" even uses them).
* prefs to configure profiles with colours, programs to start etc.
That's also there.
And yes - the shell should provide the tab completion.
Really a matter of the shell, yes. Actually, pretty much anything for that is prepared, there is just too much other stuff I'm busy with. Once I get this working in the shell, a lot of old junk from ViNCed can actually go away, but that would require probably two/three month of ongoing work, spare time I simply do not have.
Anyways - all these are great reasons to rather use AROS :laughing:
Amiga is for me a retro platform. Why someone wants to implement old design errors in a new operating system is probably beyond me. But it's a free world, if you want to waste your time there, be my guest...
-
There is none. The workbench computes a suitable size from the font size and the size of the workbench screen. It's always an approximate 80x16 console window
Correct. If you need this, use CLICon or IconX. The former allows many more options.
I was hoping there was a way to start a script from workbench and get it in a fullscreen shell without relying on anything other than whats in ROM but I guess there isn't. :(
-
I was hoping there was a way to start a script from workbench and get it in a fullscreen shell without relying on anything other than whats in ROM but I guess there isn't. :(
You cannot even start the workbench by only relying on what's in ROM (note that at least "LoadWB" is disk-based), so I wonder why this is a useful criterion.
-
You cannot even start the workbench by only relying on what's in ROM (note that at least "LoadWB" is disk-based), so I wonder why this is a useful criterion.
I know that but I have a floppy that start an extremely minimalistic workbench and includes a DOS script as an install option. I'd love to be able to start that script without rely on IconX or Execute to be present, that way I can be sure it'll start no matter what device or floppy you boot from... however the shell need to be in full screen and I don't want to force the user to manually do that.
Just looking into what options I have.
1) Ignore and accept that it'll fail in the cases where user boot from a different floppy.
2) Put IconX and Execute on the floppy, however if not in the same device (say they use DF1) it'll still fail.
3) Rely solely on ROM based alternatives (doesn't seem to be possible)
4) Rely ROM based alternative in combination with 3rd party software such as CLIwindow.
-
I know that but I have a floppy that start an extremely minimalistic workbench and includes a DOS script as an install option. I'd love to be able to start that script without rely on IconX or Execute to be present, that way I can be sure it'll start no matter what device or floppy you boot from... however the shell need to be in full screen and I don't want to force the user to manually do that.
Frankly, if installation is your problem, write an installer script. Yes, that is disk-based, but my experience is:
No matter what you do, some user will screw up. Offer something that is known and convenient for 90% of the users. 10% will complain no matter what you do (and unfortunately, you will only receive feedback from them, positive feedback is rare), so address the 90% as good as you can, with the tools they know. That's the installer.
-
I was hoping there was a way to start a script from workbench and get it in a fullscreen shell without relying on anything other than whats in ROM but I guess there isn't. :(
There is, it's called the Startup-Sequence. If you wanted to, you could still load Workbench and keep the AmigaDOS shell open by omitting the EndCLI after LoadWB. That is, I'm assuming your floppy is bootable?
-
Frankly, if installation is your problem, write an installer script. Yes, that is disk-based, but my experience is:
No matter what you do, some user will screw up. Offer something that is known and convenient for 90% of the users. 10% will complain no matter what you do (and unfortunately, you will only receive feedback from them, positive feedback is rare), so address the 90% as good as you can, with the tools they know. That's the installer.
The script is quite foolproof and req. minimal input from the user and I opted for a DOS script to save space and memory (everything is archived, even bootfiles and install tools/script, and are extracted to RAM: on startup).
All I want to know is if there's a way to start the script in fullscreen from Workbench without IconX and the answer is nya... it doesn't exist in ROM, it doesn't even exist in other OS3.x files so I'd have to resort to a 3rd party tool for this and although it would solve the issue if someone try start the script when IconX isn't present I'm not sure I have the extra 2.5KB space for the extra tool. I'll have to wait and see how my project evolves.
There is, it's called the Startup-Sequence. If you wanted to, you could still load Workbench and keep the AmigaDOS shell open by omitting the EndCLI after LoadWB. That is, I'm assuming your floppy is bootable?
I understand how you're thinking and it could have been a good idea if it wasn't for the fact that Install isn't the only function of the disk and one of the others have to be started from it's icon in Workbench to work... so for a cleaner look everything goes through Workbench. But I do like your outside the box thinking. :D
-
I was hoping there was a way to start a script from workbench and get it in a fullscreen shell without relying on anything other than whats in ROM but I guess there isn't. :(
You could do this with two scripts. You double click on script1 which contains just this:
newshell con:0/0/9999/9999/Fullscreen_Shell/CLOSE/WAIT from script2
-
All I want to know is if there's a way to start the script in fullscreen from Workbench without IconX and the answer is nya... it doesn't exist in ROM, it doesn't even exist in other OS3.x files so I'd have to resort to a 3rd party tool for this and although it would solve the issue if someone try start the script when IconX isn't present I'm not sure I have the extra 2.5KB space for the extra tool. I'll have to wait and see how my project evolves.
Note, also, that starting of shell scripts from the workbench with a double click is a feature that was added to the 3.5 or 3.9 workbench. So 3.1 users will not have it. IconX is, however, part of the 3.1 distribution, so it should be on everybody's workbench in the C: directory. In worst case, you can supply a similar tool along with your program. (Hint: I would have little problems allowing that for CLICon).
However, if I may: I would still strongly suggest to use the installer. It's really what it's good for, and users know it. In the end, it's of course your decision, I'm just giving a well-meant advice.
-
You could do this with two scripts. You double click on script1 which contains just this:
newshell con:0/0/9999/9999/Fullscreen_Shell/CLOSE/WAIT from script2
Looks to be exactly what I need (was trying to do but in the wrong order I guess... executing a script and direct output it to a new CON: which didn't work since all outputs still came to the first one). Will play with this a bit but looks promising! :D
Note, also, that starting of shell scripts from the workbench with a double click is a feature that was added to the 3.5 or 3.9 workbench. So 3.1 users will not have it. IconX is, however, part of the 3.1 distribution, so it should be on everybody's workbench in the C: directory. In worst case, you can supply a similar tool along with your program. (Hint: I would have little problems allowing that for CLICon).
However, if I may: I would still strongly suggest to use the installer. It's really what it's good for, and users know it. In the end, it's of course your decision, I'm just giving a well-meant advice.
From my experienced if you set the scripts S protection bit, give it a tool icon (instead of project) and add CLI to it's tooltypes it'll start perfectly fine with just KS3.1... need to verify 3.0 compatibility though.
I understand your good intentions and I appreciate them but Installer is simply too large for this application. :(
The project is to get as much of OS3.1 onto a single DD floppy and have the floppy work as a standalone disk with all the original functionality still there and it need to work with as little as 68000 and 1MB of memory. I'll spare you the details of what I've had to do to make it work, lets just say I've optimized, crunched and packed a bit and apart from IconX's dependencies it work brilliantly and installs about 2.4MB of the original 3.1 content (so not everything but with no real "essentials" missing).
-
You could do this with two scripts. You double click on script1 which contains just this:
newshell con:0/0/9999/9999/Fullscreen_Shell/CLOSE/WAIT from script2
The code did what I expected it to do but failed to solve the imaginary issue I've created (where someone boot with a floppy that are missing key OS files and then try to access my disks). I hoped I could get around to execute my script with no diskbased dependencies cause from there I could solve all issues. With the code IconX get's taken care of but I'm still stuck with needing Execute to be present (far more likely but still not certain).
I figured the newshell likely would need the Execute command (since IconX do) but I had hoped it wouldn't (since S:startup-sec don't).
-
With the code IconX get's taken care of but I'm still stuck with needing Execute to be present.
NewShell/NewCLI does not require Execute. It's the shell that executes the commands, not Execute. Execute is just a silly preprocessor. See "THOR's Shell Hacks" here in the forum.
-
NewShell/NewCLI does not require Execute. It's the shell that executes the commands, not Execute. Execute is just a silly preprocessor. See "THOR's Shell Hacks" here in the forum.
Yes, my bad. Execute wasn't needed by newshell line but by the way I start the script from the workbench icon.
You know of any other option to get the script to start via an icon other that said option where I have to set the S bit, give the script a tool icon and add CLI to tooltypes as this requires Execute to be present and also give you a prompt for arguments. I know I could simply add "newshell from" in front of the scriptname in the prompt but that's not really an option that works for Joe Novice.
-
Yes, my bad. Execute wasn't needed by newshell line but by the way I start the script from the workbench icon.
Huh? Why? I do not really see where and why the workbench should require Execute as command. As said, the only thing the workbench does is to pipe the command name into the System() call, and that doesn't require Execute at all. Execute is not what you think. It is not responsible for command execution at all, despite its name.
-
Yes, my bad. Execute wasn't needed by newshell line but by the way I start the script from the workbench icon.
May I ask what the benefit is supposed to be by loading your install script via a Workbench icon rather than via the startup-sequence? If the user only has a broken Workbench disk or none at all, why would they not want to boot from your install disk?
-
May I ask what the benefit is supposed to be by loading your install script via a Workbench icon rather than via the startup-sequence? If the user only has a broken Workbench disk or none at all, why would they not want to boot from your install disk?
Yes it's for my OS3.1 on a single DD floppy project and therefore you might have to start HDToolbox first so you have something to install onto. And you might need to format the disk first. You might even have to get hold of L:Fastfilesystem in case you got a really old controller with it's own software that require this on file instead of taking it from ROM or have KS3.0 and want the newer one. There's also a readme you might want to read but not all the time. If it wasn't for HDToolbox everything could be setup from startup-sequence but since it isn't I want to load Workbench and have the options run from there to get a "unified" feel.
-
Huh? Why? I do not really see where and why the workbench should require Execute as command. As said, the only thing the workbench does is to pipe the command name into the System() call, and that doesn't require Execute at all. Execute is not what you think. It is not responsible for command execution at all, despite its name.
When I try it, script given the S protection bit and a tool icon that have CLI in it's tooltypes, I clearly get "Execute unknown command" before any line of code in the script has been started.
Since I don't know how, could you please tell me how you would start a script by just double clicking an icon in workbench without having to type anything manually and only using KS3.0 ROM commands (no on disk commands like IconX, Execute etc)?
-
When I try it, script given the S protection bit and a tool icon that have CLI in it's tooltypes, I clearly get "Execute unknown command" before any line of code in the script has been started.
Since I don't know how, could you please tell me how you would start a script by just double clicking an icon in workbench without having to type anything manually and only using KS3.0 ROM commands (no on disk commands like IconX, Execute etc)?
I think Thomas meant you to use
newshell con:0/0/9999/9999/Fullscreen_Shell/CLOSE/WAIT from script2
as the default tool in a project icon. I haven't tried it but it looks like it would work.
EDIT: No, don't try that as it doesn't work under 3.1 (like he said it wouldn't). If you get rid of the "newshell" part and make the default tool "con:0/0/...." then it opens a window but I don't think it's possible to make it execute commands. Thomas may know a trick or two though...
EDIT2: If you look at the Workbench:System/Shell you'll see that it uses the default tool 'CLI'... CLI is 1180 bytes (less bytes than IconX), so this is a possibility. Make the project icon, make its default tool 'CLI' and then add some tooltypes. CLI must be somewhere in the path (sys or c etc)
WINDOW=CON:0/0/500/100/title/CLOSE/WAIT
FROM=yourscript
Your icon needs to be just 1 pixel with no second image to save space.
-
If it wasn't for HDToolbox everything could be setup from startup-sequence but since it isn't I want to load Workbench and have the options run from there to get a "unified" feel.
HDToolbox doesn't need Workbench. Delete the icon (.info) here too to save space.