Tutorial/program/install: Difference between revisions
imported>OCDoc Import Imported from legacy OpenComputers documentation at ocdoc.cil.li |
First pass at cleaning up the page from mechanical import |
||
| (One intermediate revision by one other user not shown) | |||
| Line 1: | Line 1: | ||
= Tutorial: The Install Program = | = Tutorial: The Install Program = | ||
<code>install</code> is an application that comes shipped with [[openos|OpenOS]]. For most users and in most computer configurations it is expected that the primary method of installing OpenOS is by using this very same <code>install</code> application. <code>install</code> is also designed to install the software, libraries, and help scripts that come bundled with all the craftable mod-provided [[Item/loot disks|loot disks]]. | |||
To understand more about command line options for | To understand more about command line options for <code>install</code>, it is recommended to read its man pages by running <code>man install</code>, or by reading the man page online [https://raw.githubusercontent.com/MightyPirates/OpenComputers/master-MC1.7.10/src/main/resources/assets/opencomputers/loot/openos/usr/man/install here]. | ||
<code>install</code> takes the following actions | |||
=== Step One: Scan for Software to Install === | |||
First it scans for candidate source filesystems. These are filesystems, such as [[Item/loot disks|loot disks]], that can be used as a software package for installation. If more than one candidate source filesystem is found, it prompts the user, asking<pre>What do you want to install? | |||
</pre>Followed by a list of disks it found that can be installed. | |||
=== Step Two: Scan for Hard Drives === | |||
< | The next step is a scan for candidate target filesystems. These are filesystems, such as hard drives, that can be the target of an install. In the example of installing OpenOS from a loot disk to the hard drive, the hard drive is the target filesystem. Like candidate sources, if install finds multiple candidate targets, it asks the user to select one:<pre>Where do you want to install to? | ||
</pre>Followed by a list of disks it found that can be installed '''to'''. | |||
</ | |||
<pre> | === Step Three: Installation === | ||
</ | Before continuing with the install, the user is asked for confirmation to install<pre>Install OpenOS to /mnt/e03/? [Y/n] | ||
< | </pre>Confirming this step will copy the files from the (e.g.) loot disk to the target filesystem. Software installs may have an optional <code>.prop</code> file which can tell <code>install</code> whether or not to set the default filesystem the computer should boot to, what label if any to set, and whether the system should reboot when installation is complete. | ||
</ | There is also the option for software disks to provide a fully custom install experience by creating an <code>.install</code> file at the root of the disk's filesystem. After confirming the source and target, <code>install</code> will invoke <code>.install</code> if it exists in the source filesystem. | ||
< | |||
</ | |||
=== Optional Arguments === | |||
< | It is recommend to review the install man page for greater details and a full list of supported arguments. But I considered it interesting to mention here that the label of the loot disk can be used as a command line argument for install -- which will refine the candidate search to disks matching that label.<pre>install openos | ||
</pre>Note that the argument is case insensitive. In a scenario where there would have been multiple software disks available to install, specifying the label in this manner may allow <code>install</code> to reduce the candidate selection without prompting the user. | |||
</pre> | |||
</ | |||
== Installing Additional Software == | == Installing Additional Software == | ||
Besides installing loot disks (such as | Besides installing loot disks (such as OpenOS), It is intended that users can take advantage of the <code>install</code> program for custom software disks. If you are providing software distributed on a portable filesystem, you can expect <code>install</code> to be a useful utility. For this documentation we'll assume you are distributing your software via floppy disk, though <code>install</code> does not distinguish between any filesystem component, floppy or hard disk or other. | ||
The most basic and default way to use | The most basic and default way to use <code>install</code> with your software disk is to do nothing, and it'll just sort of work. <code>install</code> checks all available filesystems that have any files and considers them candidates for installation. The user is prompted to select what to install, and <code>install</code> does a very simple copy of all files in that disk to the selected destination. This is actually how OpenOS itself installs. | ||
You have some control over how install behaves by creating a custom .prop and/or a custom .install file at the root of your software distribution disk. The .prop file is expected to be a valid lua table that set optional flags for | You have some control over how install behaves by creating a custom .prop and/or a custom .install file at the root of your software distribution disk. The .prop file is expected to be a valid lua table that set optional flags for <code>install</code>. For example, the openos .prop file contents are: <code>{label = "OpenOS", reboot=true, setlabel=true, setboot=true}</code> | ||
Note that | Note that <code>install</code>'s default copy action skips .prop (.prop is not copied). | ||
==== You can set a custom label ==== | |||
<code>install</code> can refer to and label installation options. By default, <code>install</code> uses the filesystem label (or the filesystem address if no label is set). This label can be helpful for <code>install</code> and the user experience. The user can actually tell <code>install</code> what to install from a command line argument before even being prompted about install options. For example, if you type <code>install openos</code>, and in the chance there were other installation options -- <code>install</code> will only give the OpenOS option for install. It is a way for a user to specifically get what they want before being asked. In addition to this, <code>install</code> uses the same labelling logic when listing the install options. | |||
You can override the label <code>install</code> uses by defining the <code>label</code> table key in your <code>.prop</code> file. If you want your users to be able to say: <code>install my_cool_stuff</code>, you'll want to create a .prop file at the root of your software disk that is: <code>{label="my_cool_stuff"}</code> | |||
==== Be ignored (hide from install) ==== | |||
In the case that you are using <code>install</code> and also using multiple filesystems and floppies, it might become an annoyance that <code>install</code> always includes disks as candidate installation sources when you'd really just prefer it ignore it. You can create a .prop file that has <code>{ignore=true}</code> and the next time <code>install</code> is run, it won't list that filesystem as a source option. | |||
==== Custom install action ==== | |||
If you have a more complex set of operations than JUST copying files (or even setting the boot disk, setting labels, or rebooting), for example you might want to limit which files are copied, and where they are copied to (the default copy destination is the root of the target filesystem). Note that a user can control which sub directory are copied and to where using <code>install</code> arguments, but perhaps you want to make your software disk's installation a bit more supportive of the user, and you might want to configure the install steps yourself. | |||
Once a user has confirmed your software disk as the installation source, <code>install</code> will check for the existence of a <code>.install</code> file (please note that preceding dot in the filename, just like with <code>.prop</code>). IF that file exists, <code>install</code> does NOT copy any files, but instead it runs your custom <code>.install</code> as a script (and then does nothing else). Once your <code>.install</code> script is running you have full control of how to finish the install process. | |||
Your custom <code>.install</code> script is given in its loaded environment a helpful <code>install</code> table that contains all the options that the <code>/bin/install</code> program has been able to learn thus far. | |||
For example, if this was my custom <code>.install</code> script, in its entirety (yes, NO OTHER INCLUDES):<syntaxhighlight lang="lua"> | |||
for k,v in pairs(install) do | |||
io.write(k, " -> ", v) | |||
end | |||
</syntaxhighlight>This would be the output (my filesystem was mounted on /mnt/c2b, and my .prop file had <code>{label="foo"}</code>) | |||
<pre> | |||
from -> /mnt/c2b root -> label -> foo to -> // fromDir -> | |||
</pre> | </pre> | ||
The user could have also optionally used some command line args, such as: | The user could have also optionally used some command line args, such as: <code>install foo --noreboot --nosetlabel</code>. In which case I would see those values passed to my installer script. | ||
== Contents == | == Contents == | ||
{{:Tutorial/contents}} | {{:Tutorial/contents}} | ||
Latest revision as of 18:58, 25 August 2026
Tutorial: The Install Program
install is an application that comes shipped with OpenOS. For most users and in most computer configurations it is expected that the primary method of installing OpenOS is by using this very same install application. install is also designed to install the software, libraries, and help scripts that come bundled with all the craftable mod-provided loot disks.
To understand more about command line options for install, it is recommended to read its man pages by running man install, or by reading the man page online here.
install takes the following actions
Step One: Scan for Software to Install
First it scans for candidate source filesystems. These are filesystems, such as loot disks, that can be used as a software package for installation. If more than one candidate source filesystem is found, it prompts the user, asking
What do you want to install?
Followed by a list of disks it found that can be installed.
Step Two: Scan for Hard Drives
The next step is a scan for candidate target filesystems. These are filesystems, such as hard drives, that can be the target of an install. In the example of installing OpenOS from a loot disk to the hard drive, the hard drive is the target filesystem. Like candidate sources, if install finds multiple candidate targets, it asks the user to select one:
Where do you want to install to?
Followed by a list of disks it found that can be installed to.
Step Three: Installation
Before continuing with the install, the user is asked for confirmation to install
Install OpenOS to /mnt/e03/? [Y/n]
Confirming this step will copy the files from the (e.g.) loot disk to the target filesystem. Software installs may have an optional .prop file which can tell install whether or not to set the default filesystem the computer should boot to, what label if any to set, and whether the system should reboot when installation is complete.
There is also the option for software disks to provide a fully custom install experience by creating an .install file at the root of the disk's filesystem. After confirming the source and target, install will invoke .install if it exists in the source filesystem.
Optional Arguments
It is recommend to review the install man page for greater details and a full list of supported arguments. But I considered it interesting to mention here that the label of the loot disk can be used as a command line argument for install -- which will refine the candidate search to disks matching that label.
install openos
Note that the argument is case insensitive. In a scenario where there would have been multiple software disks available to install, specifying the label in this manner may allow install to reduce the candidate selection without prompting the user.
Installing Additional Software
Besides installing loot disks (such as OpenOS), It is intended that users can take advantage of the install program for custom software disks. If you are providing software distributed on a portable filesystem, you can expect install to be a useful utility. For this documentation we'll assume you are distributing your software via floppy disk, though install does not distinguish between any filesystem component, floppy or hard disk or other.
The most basic and default way to use install with your software disk is to do nothing, and it'll just sort of work. install checks all available filesystems that have any files and considers them candidates for installation. The user is prompted to select what to install, and install does a very simple copy of all files in that disk to the selected destination. This is actually how OpenOS itself installs.
You have some control over how install behaves by creating a custom .prop and/or a custom .install file at the root of your software distribution disk. The .prop file is expected to be a valid lua table that set optional flags for install. For example, the openos .prop file contents are: {label = "OpenOS", reboot=true, setlabel=true, setboot=true}
Note that install's default copy action skips .prop (.prop is not copied).
You can set a custom label
install can refer to and label installation options. By default, install uses the filesystem label (or the filesystem address if no label is set). This label can be helpful for install and the user experience. The user can actually tell install what to install from a command line argument before even being prompted about install options. For example, if you type install openos, and in the chance there were other installation options -- install will only give the OpenOS option for install. It is a way for a user to specifically get what they want before being asked. In addition to this, install uses the same labelling logic when listing the install options.
You can override the label install uses by defining the label table key in your .prop file. If you want your users to be able to say: install my_cool_stuff, you'll want to create a .prop file at the root of your software disk that is: {label="my_cool_stuff"}
Be ignored (hide from install)
In the case that you are using install and also using multiple filesystems and floppies, it might become an annoyance that install always includes disks as candidate installation sources when you'd really just prefer it ignore it. You can create a .prop file that has {ignore=true} and the next time install is run, it won't list that filesystem as a source option.
Custom install action
If you have a more complex set of operations than JUST copying files (or even setting the boot disk, setting labels, or rebooting), for example you might want to limit which files are copied, and where they are copied to (the default copy destination is the root of the target filesystem). Note that a user can control which sub directory are copied and to where using install arguments, but perhaps you want to make your software disk's installation a bit more supportive of the user, and you might want to configure the install steps yourself.
Once a user has confirmed your software disk as the installation source, install will check for the existence of a .install file (please note that preceding dot in the filename, just like with .prop). IF that file exists, install does NOT copy any files, but instead it runs your custom .install as a script (and then does nothing else). Once your .install script is running you have full control of how to finish the install process.
Your custom .install script is given in its loaded environment a helpful install table that contains all the options that the /bin/install program has been able to learn thus far.
For example, if this was my custom .install script, in its entirety (yes, NO OTHER INCLUDES):
for k,v in pairs(install) do
io.write(k, " -> ", v)
endThis would be the output (my filesystem was mounted on /mnt/c2b, and my .prop file had {label="foo"})
from -> /mnt/c2b root -> label -> foo to -> // fromDir ->
The user could have also optionally used some command line args, such as: install foo --noreboot --nosetlabel. In which case I would see those values passed to my installer script.
Contents
| Tutorials | |
|---|---|
| Mod Specific | Basic Computer - Writing Code - Hard Drives - Autorun and Startup scripts |
| Modding | Custom Architectures - IMC Messages |
| Programs | OPPM - install |
| Others | Custom Operating Systems |