I'd like to provide a program, for example a Python script, that can be run on platforms including Linux, Mac, and Windows. I want the program to read the content of a few files in the directory, and create a new file in that directory based on the content. Specifically, I want the program to find file1.txt and file2.txt, and create a new file file3.txt which is a concatenation of the first two files.
I might provide a Python script to a Linux user, and the user can run
python script.py
However, Windows does not have Python. What other choices of programs do I have that will allow it to be run on these platforms, without the user having to install anything extra?
You could use C++, but then you'd have to compile for each platform, which is sometimes more work than you'd like.
Most systems have some form of Java installed already, which could work.
Python runs on Windows, Mac and Linux, the user would just need to install it.
I am not aware of anything that will run on all OSes without any extra work. However, Java may be a good choice as it is commonly installed. You could use C++ but you would have to compile it on each machine you would like it to work on (Windows, Mac, Linux) you would also have to make sure you don't use any library that does not transfer to the other OSes.
Related
Is there a way to execute a file while i'm in cd in the kernel. I am using Unix based systems (Arch, Manjaro, MacOSX, etc). I am trying to get htop for macOSX Big Sur, and I wrote cd /Users/peter/Downloads/htop-master . What should I do to execute the file (or is there even a way to execute it) now that i am into the file? Also, I am a beginner in the unix and linux space, so I'm not the brightest out there, so any advice helps. Thank you!
First of all, make sure the file is executable, you can run:
$ chmod +x $FILE
To make it executable, where $FILE in your case is /Users/peter/Downloads/htop-master, you might need sudo privileges to run the command. After that, you run htop:
$ /Users/peter/Downloads/htop-master
If your file is executable (ie a script or binary file) it should work. However, in your question you mentioned executing a directory, while all directories are executable, it doesn't mean you can run them as programs, it means you can cd into them.
If you downloaded the source code for htop, you'd first need to build it (compile it). That process varies from program to program, but generally, there is a Makefile that handles that for you. You'd need to check the process and requirements for htop, you should be able to find that from the website where you downloaded the program.
While I don't use MacOS, I believe there is a package manager called brew that can install htop for you. A package manager is a terminal program that installs programs from trusted sources automatically, it also handles dependencies and updates for you. I highly recommend you check it out.
Finally, I'd like to clarify some terms you seem to have confused:
Kernel: The kernel is the core of the operating system, its job is to comunicate software and hardware, you don't normally interact with it, unless you are developing drivers or code that interacts in some lower level way with the hardware.
Terminal: This is what you probably meant by kernel, it is commonly a Terminal Emulator, a program that lets you use a terminal from within a graphic environment. It is usually a black box with white text (or viceversa). The name comes from the days in which computers had to be shared, every user had a terminal, a dumb box that allowed the user to interact with the computer.
Folder: While this term is completely correct, when using terminal programs, folders are more commonly referred to as Directories. Directory was the original term, but once graphical environments took off, the name Folder became more popular.
UNIX-like systems may seem complicated at first, but once you get the hang of it you'll realize they are way easier than Windows systems, welcome aboard!
I need to iteratively edit, recompile and run a C program called sum_subgiants.c through Python (using Spyder on Windows). I am using a python code that has previously worked on my colleague's Mac. I am a novice with python and have no experience with C.
There is a makefile and all relevant files stored in the same folder as sum_subgiants.c. I have tried
subprocess.run('make sum_subgiants', shell=True)
to compile and then
subprocess.call('sum_subgiants', stdin=input_file, stdout=output_fh, shell=True)
These commands do not appear to do anything. Any help in terms I can understand would be much appreciated.
I notice that there is no make command on Windows, which explains the error. Is there an alternative command that would work on Windows?
Should I expect subprocess.call to run easily after I have sorted out the make?
Since you are on Windows, everything is difficult.
You need to install a C compiler on the Windows machine.
You need to install make on the Windows machine.
Depending on what is done in the makefile, you might need to install other tools as well.
You could consider installing MSYS2 and MinGW, which provide a Unix-like environment for Windows.
But I would question the whole procedure: Why is it necessary to dynamically build a C program at run time? This is going to be so complicated that looking for an alternative solution might be preferable.
I managed to create a .deb file from a source program,tar.gz
how can i create an exe file so that the app can also run on windows?i've searched a lot but didnt manage to find any resources.
If you want to run the program under Windows, you'll need to re-compile it from source using a Windows compiler. How exactly to re-compile it will differ from program to program. Check the program's documentation for details or ask its maintainer. ".deb" files and anything else related to Linux package managers have no meaning in Windows, so you'll need to extract the source from the source .deb or pull it from the appropriate source repository.
Be aware that many Linux programs won't build for Windows with a simple recompile alone. If they use any external libraries, then those libraries need to be available for Windows as well. The Cygwin environment may help here. If there isn't already an official procedure for building that particular program under Windows, then you may have to do the porting work yourself (which is a large enough task that it's well outside the scope of this question).
I have some c code that I compile and run, in a directory that is accessible from many different unix computers (various linux and mac, occasionally others), with different OS's obviously needing different executables.
I have a simple shell script that invokes the appropriate executable, prog.$OSTYPE.$MACHTYPE, compiling it first if necessary. This is very simple (although it requires using csh in order to have $OSTYPE and $MACHTYPE be reliably defined) and it almost works.
However, it turns out that even $OSTYPE and $MACHTYPE are not enough: for example, compiling on OSX 10.5 yields an executable prog.darwin.i386 which, when invoked on OSX 10.4, crashes instantly.
Yes, recompiling every time I want to run the program is one way to solve this, but it seems excessive. I know having a bin directory on every machine is a standard solution, but a non-root user may not have much write access outside their home directory (which is common to all the machines).
So my question is, is there a better approach? The compiler (often gcc) obviously knows what kind of system it is compiling for -- is there a good portable way to find out what "kind of system" my script is running on, so it can invoke the correct executable, instead of one with undefined behavior?
You could use gcc -v to figure out what the installed/runnable gcc thinks is the target arch for hosted compiling (something like $(gcc -v 2>&1 | grep Target: | sed 's/.*: *//') in bash)
edit
If you really want to be able to do this without having anything in particular installed, you could extract the config.guess script from gcc (its in the top level directory of any gcc source package) and run that. Unfortunately this won't work for all systems and might not exactly match what the system gcc package uses for some distributions, but this is the script used to configure gcc for building unless you explicitly override it...
try to use file command from shell prompt
Download some open source packages written in C and have a look at the file ./configure which is basically a large shell script that collects info from many sources, often by compiling and running short C programs. This will tell you everything that you need to know.
Since you are dealing with recent Mac OS X make sure you choose a package that is currently being maintained and supports OS X versions.
I am in a big problem ..i have compiled my c files using linux make file in Linux OS.
I want to compile the same files in Windows using the same make file by command prompt. For that i have nmake utility and Cygwin utility too.
I have done that successfully with simple programs with simple make file ..
But it is not possible to compile when i was using the complex C files with complex make file.
I have changed the '/' in linux make file to '\' in windows? Anyother changes?
I want to know 'Is there any special make file formats in windows?'
also the difference between them..
I am really in need of that...
Unfortunately, nmake was only loosly inspired by make, and they didn't get many important things right. By far the easiest thing to do is to start by having the same flavor of make on both platforms.
On linux, Gnu make is the default and best option.
On Windows, there are several sources for Gnu make, with some quirks to choose among. Personally, I mostly use the native win32 build of Gnu make from the GnuWin32 project. You might want to poke around at the rest of the project's packages because some of the others will be useful to have as well.
Alternative sources are Cygwin and MinGW32/MSYS.
Cygwin is a credible attempt at providing a *nix compatibility environment on top of the Windows kernel. It consists of a DLL that exports a huge percentage of *nix (especially POSIX) system calls implemented via the Windows API. That DLL also has its own idea about disk mounts and prefers *nix-style path names. The DLL itself is licensed GPL (although a commercial-use license is available for a fee), and programs built in the Cygwin environment require it by default, so that can be a factor to consider. Another factor is that Cygwin is not friendly to normal Windows users, so development projects based on it usually end up difficult for non-unix users to deal with. For a cross-platform developer, however, Cygwin can be really useful as it gets you all of the usual suspect utility programs required by your Makefile, and it includes the MinGW32 native Windows targeted GCC as well as a GCC targeting the Cygwin environment.
MinGW32 is a porting project that did a really good job of porting the GCC compilers to run as native Windows executables. If used along with the header files they supply, it is possible to use nearly all of the Windows API via a C runtime DLL that ships with modern Windows installations.
MSYS is a lightweight fork of Cygwin that contains a minimal set of utilities (starting with a *nix shell) that are usually assumed to exist by a typical *nix Makefile. Unlike Cygwin, MSYS is configured such that the default target is the native Windows API.
What I'm trying to hint at here, and probably should just state flat out, is that your compatibility issues don't end with the dialect of make you use.
The Makefile language itself is highly dependent on the command shell available, and most serious project Makefiles end up using many of the *nix the core utilities such as cp and rm.
I would strongly recommend starting with the GnuWin32 build of make, and also installing MinGW32 and MSYS. It is then relatively easy to write a Makefile that works under both MSYS and linux, and needs only a small amount of platform-specific logic.
You should consider CMake for cross-platform make but your real problem is you shouldn't have to change the '/' to '\'. If you run under cygwin or msys (recommended) this should be handled for you.
NMake is a windows tool and will parse only windows-style paths, i.e. paths with drive letters and backslashes. Therefore you should use GNU Make installed with cygwin.
nmake should read your makefiles okay, the differences are generally between versions of make rather than OSs.
The big question is what your target platform actually is, are you trying to make this code operate in Windows natively or are you looking to run it under Cygwin?
Use gnumake on both platforms. I do. I haven't touched Visual C in years.
nmake got it's own format rather than windows itself, so makefile format is related to make tool rather than os. For simple things format is similar for g(nu)make and nmake, as people suggested before consider using gmake only.