Is it possible to build a basic text based shell/command line ontop of freebsd kernel? - operating-system

I am interested in operating system development and have a basic knowledge of c, c++, and java. I would like to program a custom text based shell/command line that runs on top of the FreeBSD kernel.
My question is how would I go about obtaining the kernel and writing my custom environment into it, and what tools and resources would I need.
Btw. I am also open to linux, I just prefer the BSD License.

Shell is just an ordinary program, like any other. It doesn't use any special APIs. So, you can just install FreeBSD, write the software you would like to become the shell, and just set it up as user's shell, by using chsh command.

Related

How to write a program that works on different OS?

The question I'm asking is a bit unclear, I think it's a bit hard to explain it with only one line. Here's my situation: I have a Bitbucket repertory which is cloned in both an Linux environment and Windows environment. The problem I have is:
1- I need to read and write from files and the paths to the different locations must be changed every time I commit and push. Hence, if I was working on Windows and made a push, when I go back to Linux and need to pull and change the paths I used.
2- I'm running selenium with Python. In order to make it work on my Linux serverless machine, I need to create a virtual display with pyvirtualdisplay library. Hence, some code that needs to be executed on my Linux machine must not be executed on my Windows machine.
So the problem I got is if I work on my Windows machine, I need to comment out the lines that creates the virtual display.
These two problems takes me a lot of time, because everytime I pull in a different machine, I can't directly work on the code, but have to change the code first.
Pretty simple. What you are looking for is to import the 'os' module.
import os
Then you can get the "name" of the current running Operating System by checking: os.name.
You can then base if or case statements, or however you want to manage your code, on what OS is reported.
To be clear, I would wrap the code I want to run only in a certain environment in an if statement that determines which OS is running and runs the appropriate code block based on the result.
if [[ os.name == "nt" ]]; then
;do Windows stuff
else
;do linux stuff
fi
Additional Note! That was psuedocode based on general Bash scripting.
This is Python psuedocode:
if os.name == "nt":
; Do Windows Stuff
else:
; Do Linux Stuff
Your first issue can be solved by handling the paths in a configuration file instead of hard-coding them in the program itself (and possibly using the pathlib or os.path modules for the actual path manipulations), then telling git to ignore the config file. You can then create appropriate configurations on each system, and git won't bother them at all.
Your second issue can be solved by using any of the various methods Python gives you to figure out what OS you're running on, and then using simple conditional statements to match on them. In theory, you could do the same for the paths, but it really is better in the long run to get in the habit of properly separating runtime configuration like that from program logic. Options for this include:
os.name: Contains posix, nt, or java, which identifies what type of OS you're on. java for Jython, nt for Windows,posix` for pretty much everything else. Useful when you just care about certain low-level OS semantics.
sys.platform: Contains a generic name for the underlying OS ABI. win32 for Windows, darwin for macOS, linux for Linux, and the name of the OS for other UNIX variants. This lets you check for particular underlying platforms, and is generally what you should use for conditional code that only runs on one platform. Make sure to always check this with a construct like sys.platform.startswith('X'), as some platforms and Python implementations include version info after the OS name.
platform.system(): Similar to sys.platform, except that the returned string is more user-friendly (Windows for Windows, Linux for Linux, etc), and it returns an empty string if it can't figure out what OS you're on. Useful for displaying the OS to the user, but not for doing conditionals (because it's free-form and may not always return useful information).

shell script vs. perl for an install script - how ubiquitous is perl?

I am wanting to create an install script in the fashion of npm's (curl http://example.com/install.sh | sh) but it leaves me asking the question: can I just write the script in perl? As far as I know, perl is installed by default on at least ubuntu, RHEL & OS X - so I'm wondering in the year 2011, can I not write shell and still be generic enough for everyone? Is there a third and better option?
This would be targeting a user's development box, not staging or production.
What I want to do specifically is use this install script to bootstrap a development environment easily without the overhead of creating and maintaining packages. The script would have 4 steps:
check and make sure git is installed
use git to clone a repo to cwd
pull down and save a perl control script to /usr/bin, make it executable
add some environment variables (related post: linux cross-distro environment variable modification via script?)
That's it. My thinking is this is simple and generic enough to use a bootstrap script rather than a package. And my target audience is a user's unix or linux local development system.
The best option is to simply use the existing, well-oiled and -used (development) toolchain for the language the target app is written in. Not doing so frivolously discards the network effects gained from the ecologies that have grown around them.
C: GNU autotools
Haskell: Cabal
Perl: EU::MM, M::B, M::I
etc. etc.
Installing from the Web should be reserved for conveniently bootstrapping a user's system into the development environment.
Do tell more details about your software to get less general advice.
Edit: response to your addendum.
I dissuade you from a Web installer. This isn't bootstrapping an installation tool, this is plain installation of software and it should be done with with e.g. a Module::Build subclass.
I think perl is ubiquitous enough for you to write your installer in it. Shell is a lot more awkward anyway.
You might want to consider actually packaging your application as a deb or rpm or even using makeself rather than providing a raw script.
Here's a list of the various distributions of perl:
https://www.socialtext.net/perl5/distributions
Even if perl doesn't ship on every little obscure distro it's just an apt-get (or whatever) away. You might run into problems due to the various versions of perl installed however.
Use something like:
perl -E "$( wget -q -O - http://host/intall.pl )"
Also you can use
`cmd`
instead of
$(cmd)
but anyway, double-quote your choice.

Packaging a simple perl script for use by "average Joes" running Windows

I have a really trivial perl script that I would like to distribute to a number of clients who are not very computer savvy. They are all running Windows XP or above. Furthermore, it is safe to assume that they do not have Perl installed on their systems.
I'm looking for a Perl module or other solution that would allow me to do the following:
The application should auto start upon login and minimize to the system tray until the user expands it by clicking on the system tray icon.
When expanded from the system tray the application should provide a simple Windows GUI to the script. The GUI is super trivial: a status line showing the status of the application and a "Do stuff" button that will trigger the processing of the applications business logic.
Windows-style ideally wizard based installation. I'd like to be able to able to distribute an [application-name]-install.exe that would guide the user through the installation. Perl plus dependencies should be installed behind the scene.
Are there any Perl GUI toolkits and/or installation tools that would help me achieve these things?
Win32::SysTray
Win32::GUI
PAR::Packer provided executable wrapped into NSIS
There are many more ways to do it. I think these modules will get you started most easily.
I am using perlapp from ActiveState to compile scripts into self-contained exe. It is commercial, but did not have problems I sometimes ran into with PAR/pp.
When I need to package more than just .exe (database drivers, configuration, templates, etc), quick installer can be made with InnoSetup.

Easiest language to produce a Windows executable to prefix running another executable with system calls?

I want to run some system commands (to fix things) before running an executable. I have a reasonably locked down (work) Windows XP system and so can't change what a shortcut points to. For my users' convenience, I must keep the same shortcut. However, I am able to swap out the .exe (renaming) and potentially replace it with another .exe (of the same name) which runs my system commands and then runs the original .exe.
What would be the easiest and quickest language/compiler to do this in? Previously, I've done this sort of thing in C (and tried it today in Python using py2exe without much success). Preferably free solutions.
Visual C# 2008 Express Edition is
free
comes with a compiler
outputs exes
C# is a good choice if you have C
experience
.net currently is the "canonical"
Windows platform

How can I package my Perl script to run on a machine without Perl?

People also often ask "How can I compile Perl?" while what they really want is to create an executable that can run on machines even if they don't have Perl installed.
There are several solutions, I know of:
perl2exe of IndigoStar
It is commercial. I never tried. Its web site says it can cross compile Win32, Linux, and Solaris.
Perl Dev Kit from ActiveState.
It is commercial. I used it several years ago on Windows and it worked well for my needs. According to its web site it works on Windows, Mac OS X, Linux, Solaris, AIX and HP-UX.
PAR or rather PAR::Packer that is free and open source. Based on the test reports it works on the Windows, Mac OS X, Linux, NetBSD and Solaris but theoretically it should work on other UNIX systems as well.
Recently I have started to use PAR for packaging on Linux and will use it on Windows as well.
Other recommended solutions?
In addition to the three tools listed in the question, there's another one called Cava Packager written by Mark Dootson, who has also contributed to PAR in the past. It only runs under Windows, has a nice Wx GUI and works differently from the typical three contenders in that it assembles all Perl dependencies in a source / lib directory instead of creating a single archive containing everything. There's a free version, but it's not Open Source. I haven't used this except for testing.
As for PAR, it's really a toolkit. It comes with a packaging tool which does the dependency scanning and assembly of stand-alone executables, but it can also be used to generate and use so-called .par files, in analogy to Java's JARs. It also comes with client and server for automatically loading missing packages over the network, etc. The slides of my PAR talk at YAPC::EU 2008 go into more details on this.
There's also an active mailing list: par at perl dot org.
It is some time since this question was first asked, but Cava Packager can currently produce executable packages for Windows, Linux and Mac OS X. It is no longer Windows only.
Note: As indicated by my name, I am affiliated with Cava Packager.
I'm a Perl newbie and I just downloaded Cava Packager and that's the only one I found working. I've tried ActiveState 5.10.1005 and Strawberry Perl with PAR-Packager on Windows XP.
pp just hangs in mid-stream and no executables created.
Cava provides the only solution to creating exe on Windows so far. Thks.
You could use the perlcc tool that's shipped with most distributions of Perl. I've also found both perl2exe and Active State's Perl Dev kit useful for shipping Perl applications.