I have spent time working on a bioinformatics project and produced numerous scripts and now I would like to use them for building a bioinformatics software that runs in the command line terminal, with the costumary manual and binary files. I would like to be able 1. to protect the code, 2. Make it fancy by not having to count with multiple scripts and 3. share the code with any one interested.
Since I don't really know where to start from, I would like to ask for orientation on the topic. I have been reading about script compilation and I think this could work, but I have scripts in three different coding languages, mainly python and bash, so I have not seen any tutorial on this specific case.
Any help as sharing resources (videos, manuals, software, etc.) or giving tips is appreciated. I know this is a VERY open question, so open answers are also welcome.
You could use the python argparse library to build a command line application that accepts arguments and flags. With this method, you can provide flags for user input and run your different scripts, including the bash scripts, based on user input.
https://realpython.com/command-line-interfaces-python-argparse/
Similarly, you can do this in a bash script that provides the user with options and run your other scripts based on input.
https://www.redhat.com/sysadmin/arguments-options-bash-scripts
I'm not sure what you mean by protect the code? If you mean hide the code, as far as I know, you cannot easily hide bash and python code or turn them into binaries if you want to share the script.
Related
I now know how to use the APL interpreter, but I'm quite confused about how to write APL into a file and then run the said file. I currently write Dyalog APL using the ride IDE. What I now want to do is to:
Use the ride IDE to develop programs (how else do I access the keybindings?).
Save my program to a file.
Run the program from the command line, with command line arguments (how do I take command-line arguments?)
Distribute my program so others can use them.
Most of the documentation online refers to an "APL session", which makes me think that perhaps there's some Smalltalk like thing going one, where one can only distribute the "live image" or some such. If that is the case, I have a different set of questions:
How do I save and load these image files?
How do I distribute image files?
Can I execute such code from the command line, to take command-line arguments?
In general, I'm quite confused about how to write software in APL!
EDIT: I'm on Ubuntu, and I'd like to target Linux in general. Windows/macOS support would be a plus, but I'm currently interested in Linux support.
For now, the ability to create a stand-alone executable (a single .exe file) only exists on Windows, but Dyalog is working on making this possible cross platform. However, you can get pretty close. Before we get to that, let me answer your initial questions:
Use the ride IDE to develop programs (how else do I access the keybindings?).
There are several convenient ways to enter the glyphs outside RIDE, both through editor extensions and separate system-wide methods for prefix and/or shifting key input. For details, have a look at APL Wiki's article on typing glyphs.
Run the program from the command line, with command line arguments (how do I take command line arguments?)
⊢2⎕NQ#'GetCommandLineArgs' returns the command and the arguments to the command that was used to start the current application. This works cross-platform. Try it online under Linux!
The "live image" you talk about would be what APLers call a workspace. Once your application is working as you want, enter set the ⎕LX (Latent eXpression) variable to a statement that starts your application and then closes APL when done, e.g. ⎕LX←'myApp.Run ⋄ ⎕OFF'.
Next, save your application as a workspace with )save /tmp/myapp.
You should now be able to run your application with dyalog -hello=world /tmp/myapp etc. You can of course put this in a shell script for ease of use.
What you'll distribute to your customers would at a minimum be the workspace and the runtime interpreter, but you probably want to package some companion files/dependencies too. However, before making money off your application, look at Dyalog's prices and Licences.
This is how I do it (not an official Dyalog recommendation):
Use the ride IDE to develop programs (how else do I access the keybindings?).
RIDE is cool (I'm biased), especially in the beginning when you want to explore the language interactively.
But in practice I prefer to edit plain text files with Vim with this plugin.
It provides keybindings with a configurable prefix key.
I think there's also a way to configure Vim or Emacs as an external editor for RIDE - that way you could have both the shiny session interface and the brutally efficient editor familiar to your fingers.
Alternatively, for the keybindings you could do:
setxkbmap -layout us,apl -option grp:win_switch
Pressing the "Windows key" and another key together inserts an APL char in any X11 app - convenient for email, chat, etc.
Save my program to a file. Run the program from the command line,
I put this on top:
#!/bin/bash
(echo ∇M;tail -n+3 $0;echo -e '∇\nM\n⎕off')|dyalog -script;exit $?
⎕io←0⋄⎕ct←0⋄⎕pw←32767 ⍝ opinionated :)
and do
chmod +x file.dyalog
./file.dyalog
with command line arguments (how do I take command line arguments?)
That's a bit of a problem. There's 2⎕NQ#'GetCommandLineArgs' for Windows but no working solution I'm aware of for Linux.
See the comments below and Adám's answer.
Distribute my program so others can use them.
Any way you like - github, gitlab, bitbucket, your own site, pigeons, etc
"APL session"
That's just the traditional APL term for "REPL".
I have a list of Unix commands that is used to install our software. Instead of copy and pasting the commands one by one into a terminal, I would like to present the list in a GUI front end, so that the person installing it just needs to click a button next to the command to execute it.
The timestamp should be logged as well as the status (execution in progress or exited). As the list of commands changes for each installation and can be executed in parallel or in a specific order, the GUI front end should be able to reflect these changes easily.
Is there an existing tool that already provides such a front end given a list of Unix commands? If not, which tool do you recommend to use to develop such a front end?
You could probably use something like Zenity, or maybe gtkdialog, if either are available on your platform and/or you can include them with the software you want to install.
I would use Tcl/Tk, though a solution with Python and either Tkinter or wxPython would be equally easy if you're familiar with Python. Both those languages, as well as many other dynamic languages, make it pretty easy to do tasks like this. If you know some other dynamic language (ruby, groovy, perl, etc) there's a good chance it has a GUI toolkit you could use.
Is there a standard(ish) POSIX way of determining if my process (I’m writing this as a Ruby script right now; but I’m curious for multiple environments, including Node.js and ISO C command-line applications) is being run in an interactive terminal, as opposed to, say, cron, or execution from another tool, or… so on and so forth.
Specifically, I need to acquire user input in certain situations, and I need to fail fatally if that is determinably not possible (i.e. being run by cron.) I can do this with an environment variable, but I’d prefer something more standard-ish, if I can.
I've always used $stdout.isatty to check for this. Other approaches might include checking the value of ENV['TERM'] or utilizing the ruby-terminfo gem.
The closest you'll get, AFAIK, is isatty(). But as the page itself says, nothing guarantees that a human is controlling the terminal.
As #Mitch wrote it in a comment, which can also be useful to some people:
For anyone who came here looking for windows, try System.Environment.UserInteractive for .Net or GetUserObjectInformation for win32, which will fail for non-interactive processes
I write many scripts at home and on the job. Most of the time the scripts get used only a few times to accomplish their chosen task and then are never used again. However, sometimes I write a script to do something more complicated, something that requires user input. It is at this point that I usually agonize over whether to implement a GUI or stick with a y/n, press 1-10, etc. command-line interface. This type of interface can become tedious to use and difficult to maintain.
I know some things lend themselves to a GUI more than others, such as selecting things in a giant list. However, the time it takes to switch a command-line application to use a GUI is prohibitive. For me, it takes a good amount of time to add a GUI with even the most simple framework I can find.
I am curious if any developers have a method of determining at what point their script has grown enough to need a GUI. Or am I going about this the wrong way, should I always be writing my scripts assuming I might later add a GUI?
This doesn't answer your question but FWIW an intermediate step, between UI and command-line, is to have a configuration file instead of a UI:
Edit the configuration file
Run the program
A configuration file format can, if necessary, be complicated and well-commented.
As with many questions of this type, the answer is that it depends.
If your program/script does just one single thing by receiving a number of inputs from the user, it is better to stick with the non-GUI mode.
If the application is doing more than one thing and if you think that the user will use the application to do a lot of stuff, you may consider using a GUI.
Are you planning to distribute this program to others? Then it is better to provide a GUI.
If the users are non-technical, a GUI is a must!
Thats it.
When you want to hand your stuff over to someone else in a discoverable way. Command-line scripts are awesome because they are simple and elegant, but they are not very discoverable. That is, if you were to hand your scripts over to someone else with no documentation, would they be able to figure out what they are and how to use them? If your tasks are so simple that myscript /? will explain what you need to do fully, then you don't need a GUI.
If on the other hand, you are handing your scripts over to someone who isn't so technical, or needs some more visual guidance about the task to be done, than by all means, a GUI is a good way to go. You might even want to keep your scripts as they are and just create a separate GUI that runs them for maximum flexibility.
I think this decission also depends on the audience who will be using your script: If it is people who are comfortable working with the command line, then there is not pressing need to add a GUI as long as your script has a good /help which explains all the parameters it accepts. But if you want the "average user" to be able to use your program, I'd rather add a GUI because otherwise your program might not be intuitive enough for that user group.
If you only need some "Dialogs" to improve your scripts, you can use KDE Kdialog or Gnome Zenity.
I can't count the number of times I've written what I thought would be a 'one-off' and it became more useful than I thought and ended up writing a GUI for it, or I've need to come back to use a program months later. The advantage of the GUI is it makes it easier to remember what would otherwise likely be command line arguments. I.e. for flags and options you can simply use check boxes, combo boxes, radio buttons, and file selectors filenames. I use Borland C++ RAD so it is quite quick and easy to throw together a simple (or even not so simple) dialog box. I now often start with creating the GUI.
If you use Linux, try Zenity. It's an easy to use tool to make a GUI for command-line programs.
Terminals and shells are very powerful but can be complicated to learn, especially to get the best out of them. Does anyone know of a more GUI based command shell that helps a user or displays answers in a more friendly way? I'm aware of IPython, but even the syntax of that is somewhat convoluted, although it's a step in the right direction.
Further to this, results could be presented graphically, e.g. wouldn't it be nice to be able to pipe file sizes into a pie chart?
Hotwire is an attempt to combine the power of the traditional command line interface with GUI elements. So it has a GUI side, and tries to be helpful in suggesting commands, and in showing you possible matches from your history. (While there are keyboard shortcuts to do this in bash and other shells, you have to know them ...)
You can use all your common system commands, but a number of key ones have new versions by default which use an object pipeline, and are displayed with a nice GUI view. In particular ls (aka dir) shows lists files and shows them in columns. You can sort by clicking on the column headers, double click on files to open, or double click on directories to move to that directory. The proc command allows you to right click on a process and one of the options is to kill it.
The object pipeline works in a similar way to Microsoft Powershell, allowing commands in the pipe to access object properties directly rather than having to do text processing to extract it.
Hotwire is cross platform (Linux, BSD, Windows, Mac), though it is at an early stage of development. To learn more, install (click on the link for your platform) and work through the simple getting started page.
If you don't like hotwire, you could also look at the list of related projects and ideas maintained on the hotwire wiki.
fish is a Unix shell that focuses on user-friendliness, such as by providing colored highlighting and extensive tab completion.
For a different kind of blend of textual and graphical interface, there's Quicksilver, as well as similar/inspired tools like Launchy, GNOME Do and ENSO.
Is this for Python in particular, or are you just interested in any command shell that has a GUI interface?
If the idea of piping file sizes into a pie chart interests you, you might try PowerGUI, a GUI layer on Microsoft's PowerShell command shell. PowerShell also lets you pipe data from commands into XML, CSV, and other formats that are understood by GUI programs.
GUI-based command shell seems like an oxymoron to me.
Not really? A command shell is just an encapsulated environment in which to execute commands. Why can't they have GUI extensions? We are in the 21st century! :)
Check out http://hotwire-shell.org/
This is along the lines of what I was thinking. It's a shame it uses PyGTK, I'd have preferred PyQT (perhaps a licensing issue?). There look to be some interesting related links from the project as well.
If the idea of piping file sizes into a pie chart interests you, you might try PowerGUI, a GUI layer on [...]
PowerGUI looks like a hobby project I've been working on that organises regularly used tasks. It looks like it organises frequent jobs and formats the output for you. The formatting I see as the end result of the data flow. But it would be nice to be able to tinker with data and then continue to use it.
PowerShell as a command shell is very forgiving for new users and is easy to learn. There is an add-on product (it is a commercial product) called PowerGadgets that would let you pipe file sizes into a pie chart or other types of displays
PowerGadgets looks very interesting. It would be interesting to have things like system monitors so that you could say, read the CPU usage per second and pipe it into a graph.
Is this for Python in particular, or are you just interested in any command shell that has a GUI interface?
Any really, currently, but I like the idea of cross platform, easy to edit, no compiler setup. I use Windows at work and Windows/Linux (Ubuntu)/OSX at home. Python is just an easy solution, and for writing stuff like this is has a lot of libraries already.
Thanks for all the links. Keep them coming. :)
I'm not sure whether you're asking for a shell as in bash/csh, or a shell as in ipython. If it's the later, then I'd recommend looking at Reinteract. While it's still very alpha, it's already a great tool for rapid prototyping in python, and allows embedding of plots, widgets, etc.
GUI-based command shell seems like an oxymoron to me.
The key-word here is Graphical.
If I want a GUI, I want a full-featured GUI. But if I want raw performance, I want a command line.
I'm not exactly sure what you're asking for. You can either have a GUI or a command line. What do you need from a graphical command shell that you couldn't get from a straight GUI?
Also, if you want graphical information about file sizes there are a few applications that do that. One example is WinDirStat.
Also not related to Python, but Ubiquity (a firefox extension) is a graphical command-line-like tool for the web, with a similar spirit to Quicksilver/Launchy/GnomeDo.
I know that Automator in Mac OS X is not a shell but it is the best graphical tool I have ever used to do batch tasks. I think it is worth mentioning here as even I (self-titled as a power user) use it from time to time to rename files or other routines. Although these could be done in a few lines of shell script, the Automator's graphical interface makes me feel like I am not working and it just works.
Check out http://hotwire-shell.org/
PowerShell V2 is developing a graphical command shell, but I don't think that is what you are looking for.
PowerShell as a command shell is very forgiving for new users and is easy to learn. There is an add-on product (it is a commercial product) called PowerGadgets that would let you pipe file sizes into a pie chart or other types of displays. Information about that can be found here.
As for ease of use, PowerShell command follow a Verb-Noun pattern (along with aliases for ease of use from the command line) and is very discoverable. Check out some screencasts I did on using PowerShell at PowerShell Basics.
I found POSH, a GUI for MS PowerShell. This is pretty much what I intended. You have a command-line backend with a WPF GUI frontend. You can pipe results from command to the next and show graphical output.
Maxima provides a mathematical shell (screens) . It is nice that you type in a C-like syntax and receive graphically formatted output.