The "UNIX Programmer's Manual" [1] by Ken Thompson and Dennis Ritchie says this:
Commands are programs intended to be invoked directly by the user, in
contradistinction to subroutines, which are intended to be called by the
user’s programs. Commands generally reside in directory /bin (for binary
programs).
How do you decide whether a program should be made into a command and run at the shell versus made into a subroutine that is called by other programs?
[1] https://www.bell-labs.com/usr/dmr/www/manintro.pdf, page ii.
The audience. It is rather something to be used by system admins (which devs also play the role of from time to time) or an API to help developers build systems.
But they are not exclusive. Many times you have the same software packaged as both. For example, OpenSSL is mostly an API that is largely used by the industry for encryption affairs but the package also includes commands that can be run on the shell. XZ is a compression tool that you can run on the command line but it also provides an API for programs to call to compress their data.
So you can definitely package your code as both an API and a command. It comes down to how much extra work you are willing to put to format and maintain both. In some cases it does not make sense to do both like a math library like Armadillo for example - you just don't run math commands on a daily basis.
Similar to the linux execve(3) syscall, I want to replace the current process with a new one in Rust, in a way that works on both Unix and Windows systems. I'm fine with using crates if necessary, although I would like to stay away from unsafe.
So far, the only thing I've found in the standard library is std::os::unix::process::CommandExt::exec, but this only works on Unix. Looking for crates, I found the exec crate, but it doesn't appear to support Windows. However, this open PR mentions that it's possible to use the wexecvp syscall on Windows to achieve the same functionality, although it doesn't work on the Windows Runtime and only works on Win32. (That's good enough for me, though.) I'm at a dead-end on how to do this without breaking out libc::wexecvp and unsafe.
Is there a way to replace the current process with a new one in a cross-platform way in Rust?
This is a question that is independent of the programming language used, because it's about the process models of operating systems.
The answer is simply No.
The Windows process model doesn't work this way -- it's not a *nix.
Some things are fundamentally nonportable. So, you'll need to figure out what your functional requirement is (e.g. stdio handle inheritance, permissions, environment, etc.), and how to implement that on the other platform(s).
I can't get more specific because you'd need to provide more details on what "replace the current process by another one" means for your app You can always launch another program and quit, which naively sounds like the same thing :-).
I'd like to write a x11 terminal emulator, but I don't know how I should spawn and communicate with the shell, is there any basic (pseudo- or C) code for that? like what sort of PTY to create, how to bind the shell to it, what signals I have to catch or send, etc. don't really feel like sorting through the whole xterm sources.
EDIT: oh and I want to implement a way of communicating with any applications in it, how shall I do the feature discovery? some hidden ansi sequence in the "clients", hoping it's not colliding with other terminal emulators? some environment variable, hoping it's not colliding with the "clients" or removed by the shell?
YAT (yet another terminal) https://github.com/jorgen/yat is suitable for embedding in Qt Quick programs. Contributions for improvement are welcome. (Disclaimer: a friend started that project, and I work on it sometimes.) It takes a mostly correct approach (e.g. it uses a Linux pseudo-terminal properly, something I didn't know about before my friend was explaining that), and has a lot of features; however the parser is written from scratch and is not feature-complete or bug-free yet.
Unfortunately most terminal implementations so far have been starting from scratch, or with a one-off monolithic fork (from rxvt for example), which is a lot of work and results in all of them being incomplete. So I think a better alternative would be to use a reusable logic-only library called libvterm: http://www.leonerd.org.uk/code/libvterm/ or to base your terminal on one which already uses that. That way if you find bugs and fix them, you'll improve the whole ecosystem.
https://github.com/timmoorhouse/imgui-terminal is interesting, and works (at least somewhat) but is a prime candidate to be rewritten with libvterm, IMO. If you are into immediate-mode rendering in OpenGL, it might be a good choice anyway.
http://41j.com/hterm/ does use libvterm, and adds a few features which libvterm doesn't have, for inline graphics rendering (ReGIS and PNG). But the code is not elegant enough or portable enough, IMO, and the graphics rendering "floats" over the text rather than being truly inline. It still might be an adequate starting point for some use cases. In my fork https://github.com/ec1oud/hackterm I got it to build with mostly modern system libraries, however it still depends on an outdated version of SDL, which is included.
OK, if anyone also need this, and is using lua, I found the http://www.tset.de/lpty library works fine. still testing ansi escapes and stuff, but should work.
I'm attempting to test an application which has a heavy dependency on the time of day. I would like to have the ability to execute the program as if it was running in normal time (not accelerated) but on arbitrary date/time periods.
My first thought was to abstract the time retrieval function calls with my own library calls which would allow me to alter the behaviour for testing but I wondered whether it would be possible without adding conditional logic to my code base or building a test variant of the binary.
What I'm really looking for is some kind of localised time domain, is this possible with a container (like Docker) or using LD_PRELOAD to intercept the calls?
I also saw a patch that enabled time to be disconnected from the system time using unshare(COL_TIME) but it doesn't look like this got in.
It seems like a problem that must have be solved numerous times before, anyone willing to share their solution(s)?
Thanks
AJ
Whilst alternative solutions and tricks are great, I think you're severely overcomplicating a simple problem. It's completely common and acceptable to include certain command-line switches in a program for testing/evaluation purposes. I would simply include a command line switch like this that accepts an ISO timestamp:
./myprogram --debug-override-time=2014-01-01Z12:34:56
Then at startup, if set, subtract it from the current system time, and indeed make a local apptime() function which corrects the output of regular system for this, and call that everywhere in your code instead.
The big advantage of this is that anyone can reproduce your testing results, without a big readup on custom linux tricks, so also an external testing team or a future co-developer who's good at coding but not at runtime tricks. When (unit) testing, that's a major advantage to be able to just call your code with a simple switch and be able to test the results for equality to a sample set.
You don't even have to document it, lots of production tools in enterprise-grade products have hidden command line switches for this kind of behaviour that the 'general public' need not know about.
There are several ways to query the time on Linux. Read time(7); I know at least time(2), gettimeofday(2), clock_gettime(2).
So you could use LD_PRELOAD tricks to redefine each of these to e.g. substract from the seconds part (not the micro-second or nano-second part) a fixed amount of seconds, given e.g. by some environment variable. See this example as a starting point.
Is there a programming language which can be programmed entirely in interactive mode, without needing to write files which are interpreted or compiled. Think maybe something like IRB for Ruby, but a system which is designed to let you write the whole program from the command line.
I assume you are looking for something similar to how BASIC used to work (boot up to a BASIC prompt and start coding).
IPython allows you to do this quite intuitively. Unix shells such as Bash use the same concept, but you cannot re-use and save your work nearly as intuitively as with IPython. Python is also a far better general-purpose language.
Edit: I was going to type up some examples and provide some links, but the IPython interactive tutorial seems to do this a lot better than I could. Good starting points for what you are looking for are the sections on source code handling tips and lightweight version control. Note this tutorial doesn't spell out how to do everything you are looking for precisely, but it does provide a jumping off point to understand the interactive features on the IPython shell.
Also take a look at the IPython "magic" reference, as it provides a lot of utilities that do things specific to what you want to do, and allows you to easily define your own. This is very "meta", but the example that shows how to create an IPython magic function is probably the most concise example of a "complete application" built in IPython.
Smalltalk can be programmed entirely interactively, but I wouldn't call the smalltalk prompt a "command line". Most lisp environments are like this as well. Also postscript (as in printers) if memory serves.
Are you saying that you want to write a program while never seeing more code than what fits in the scrollback buffer of your command window?
There's always lisp, the original alternative to Smalltalk with this characteristic.
The only way to avoid writing any files is to move completely to a running interactive environment. When you program this way (that is, interactively such as in IRB or F# interactive), how do you distribute your programs? When you exit IRB or F# interactive console, you lose all code you interactively wrote.
Smalltalk (see modern implementation such as Squeak) solves this and I'm not aware of any other environment where you could fully avoid files. The solution is that you distribute an image of running environment (which includes your interactively created program). In Smalltalk, these are called images.
Any unix shell conforms to your question. This goes from bash, sh, csh, ksh to tclsh for TCL or wish for TK GUI writing.
As already mentioned, Python has a few good interactive shells, I would recommend bpython for starters instead of ipython, the advantage of bpython here is the support for autocompletion and help dialogs to help you know what arguments the function accepts or what it does (if it has docstrings).
Screenshots: http://bpython-interpreter.org/screenshots/
This is really a question about implementations, not languages, but
Smalltalk (try out the Squeak version) keeps all your work in an "interactive workspace", but it is graphical and not oriented toward the command line.
APL, which was first deployed on IBM 360 and 370 systems, was entirely interactive, using a command line on a modified IBM Selectric typewriter! Your APL functions were kept in a "workspace" which did not at all resemble an ordinary file.
Many, many language implementations come with pure command-line interactive interpreters, like say Standard ML of New Jersey, but because they don't offer any sort of persistent namespace (i.e., when you exit the program, all your work is lost), I don't think they should really count.
Interestingly, the prime movers behind Smalltalk and APL (Kay and Iverson respectively) both won Turing Awards. (Iverson got his Turing award after being denied tenure at Harvard.)
TCL can be programmed entirely interactivly, and you can cetainly define new tcl procs (or redefine existing ones) without saving to a file.
Of course if you are developing and entire application at some point you do want to save to a file, else you lose everything. Using TCLs introspective abilities its relatively easy to dump some or all of the current interpreter state into a tcl file (I've written a proc to make this easier before, however mostly I would just develop in the file in the first place, and have a function in the application to resources itself if its source changes).
Not sure about that, but this system is impressively interactive: http://rigsomelight.com/2014/05/01/interactive-programming-flappy-bird-clojurescript.html
Most variations of Lisp make it easy to save your interactive work product as program files, since code is just data.
Charles Simonyi's Intentional Programming concept might be part way there, too, but it's not like you can go and buy that yet. The Intentional Workbench project may be worth exploring.
Many Forths can be used like this.
Someone already mentioned Forth but I would like to elaborate a bit on the history of Forth. Traditionally, Forth is a programming language which is it's own operating system. The traditional Forth saves the program directly onto disk sectors without using a "real" filesystem. It could afford to do that because it didn't ran directly on the CPU without an operating system so it didn't need to play nice.
Indeed, some implementations have Forth as not only the operating system but also the CPU (a lot of more modern stack based CPUs are in fact designed as Forth machines).
In the original implementation of Forth, code is always compiled each time a line is entered and saved on disk. This is feasible because Forth is very easy to compile. You just start the interpreter, play around with Forth defining functions as necessary then simply quit the interpreter. The next time you start the interpreter again all your previous functions are still there. Of course, not all modern implementations of Forth works this way.
Clojure
It's a functional Lisp on the JVM. You can connect to a REPL server called nREPL, and from there you can start writing code in a text file and loading it up interactively as you go.
Clojure gives you something akin to interactive unit testing.
I think Clojure is more interactive then other Lisps because of it's strong emphasis of the functional paradigm. It's easier to hot-swap functions when they are pure.
The best way to try it out is here: http://web.clojurerepl.com/
ELM
ELM is probably the most interactive you can get that I know of. It's a very pure functional language with syntax close to Haskell. What makes it special is that it's designed around a reactive model that allows hot-swapping(modifying running code(functions or values)) of code. The reactive bit makes it that whenever you change one thing, everything is re-evaluated.
Now ELM is compiled to HTML-CSS-JavaScript. So you won't be able to use it for everything.
ELM gives you something akin to interactive integration testing.
The best way to try it out is here: http://elm-lang.org/try