I have written a suite of programs that is supposed to work on both MacOS X and on GNU/Linux. For most components, the code is identical for both MacOS X and for GNU/Linux - however there are a few low-level commands for which (based on auto-detection) the installer will install an implementation of the tool specific to your operating system - which (as I said) is for the time being either MacOS X or GNU/Linux.
The thing is - for these low-level commands that have different implementations for different systems, each command will require two man-pages to be installed - one which describes the usage and behavior of the command independently of what system/implementation you are using - and another which merely documents specifics for the specific system's implementation of the command.
So my question is -- does the man command offer a way to distinguish between two such man-pages? And if so, what is it?
I already have a solution for when you access the man-pages through the command's own --help option (basically, that the generic man-page is what you see when you invoke the command with the --help option itself - yet the generic man-page includes instructions as to what option will display the implementation-specific man-page) but I'm now getting to the part where I will be writing the capability for the program's installer to install the man-pages where they can actually be accessed through the man command, and therefore, where these low-level commands are concerned, I need to know if there is a way to distinguish between these two distinct man-pages for the same command.
Related
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).
I'm running the tcl(which has expect script) using perl with,
system("C:/Tcl/bin/tclsh86 C:/Users/sysadmin/desktop/expect.tcl");
It's not executing the all commands in the script, but its working fine on ubuntu.
What command should i use to run this completely using perl on Windows?
On Unix Expect works using virtual terminals. By contrast, Expect on Windows uses the debugging subsystem. (There's nothing like virtual terminals on Windows.) This has the down-side that programs that are marked as being impossible to debug (i.e., some system programs, notably including telnet.exe though ftp.exe might also be on that list) cannot be automated by Expect at all. The OS just refuses to let Expect connect to the process.
Is this what is happening to you? I can't tell from the minimal information you've given, but it is by far the most common reason for problems with porting an Expect script between platforms (once you've taken into account mundane things like different paths and programs that just aren't there on all platforms).
The up-side is that both Tcl and Perl are quite capable of talking directly to anything that you'd use telnet or ftp to talk to (as both are entirely proficient at TCP/IP). In fact, both are probably better at doing it natively than anything you'd likely achieve through use of Expect.
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.
Looking to execute a perl script on a remote machine via a Perl script. Appears one option is to use system() function and create an ssh key so the password is not required. Which leads me to the focus of this question, the other option appears to be to install and run one of these perl modules:
Net::SSH
Net::SSH2
Net::OpenSSH
Besides the protocol used, what else should I be comparing with these Perl modules?
The Net::OpenSSH documentation has a section describing the pros and cons of each. Here are some excerpts related to the ones you are asking about, but the documentation lists more:
Net::SSH is just a wrapper around any
SSH binary commands available on the
machine. It can be very slow as they
establish a new SSH connection for
every operation performed.
Net::SSH2 is much better than
Net::SSH::Perl, but not completely
stable yet. It can be very difficult
to install on some specific operative
systems and its API is also limited,
in the same way as Net::SSH::Perl.
Net::OpenSSH has a very perlish
interface. Most operations are
performed in a fashion very similar to
that of the Perl builtins and common
modules (i.e. IPC::Open2).
However, choice of platform may limit your options.
On the other hand, Net::OpenSSH does
not work on Windows, not even under
Cygwin.
Granted, the list is biased towards Net::OpenSSH, but it gives you an idea of the major differences between the modules.
What is a command line compiler?
Nowadays, you tend to have environments in which you develop code. In other words, you get an IDE (integrated development environment) which is comprised of an editor, compiler, linker, debugger and many other wonderous tools (code analysis, refactoring and so forth).
You never have to type in a command at all, preferring instead a key sequence like CTRLF5 which will build your entire project for you.
Not so in earlier days. We had to memorize all sorts of arcane commands to get our source code transformed into executables. Such beautiful constructs as:
cc -I/usr/include -c -o prog.o prog.c
cc -I/usr/include -c -o obj1.o obj1.c
as -o start.o start.s
ld -o prog -L/lib:/usr/lib prog.o obj1.o start.o -lm -lnet
Simple, no?
It was actually a great leap forward when we started using makefiles since we could hide all those arcane commands in a complex file and simply execute make from the command line. It would go away and perform all those commands for us, and only on files that needed it.
Of course, there's still a need for command-line compilers in today's world. The ability to run things like Eclipse in "headless" mode (no GUI) allow you to compile all your stuff in a batch way, without having to interact with the GUI itself.
In addition, both Borland (or whatever they're calling themselves this week) and Microsoft also provide command-line compilers for no cost (Microsoft also have their Express editions for free as well).
And gcc is also a command-line compiler. It does its one job very well and leaves it up to other applications to add a front end, if people need that sort of thing.
Don't get me wrong. I think the whole IDE thing is a wonderful idea for a quick code/debug cycle but I find that, once my applications have reached a certain level of maturity, I tend to prefer them in a form where I can edit the code with vim and just run make to produce the end product.
A command-line compiler is one that you run from the command line.
You type in gcc filename.c to compile a file (or something like that). Almost all compilers have a command-line version, and many have GUIs where you never see the command line, but the command line is still there. – Bill K Oct 5 at 16:27
(Bill K provided a nice answer in the comments... copied here and lightly edited by Mark Harrison, set to community wiki so as not to get rep.)