Whenever I set out to learn a language the first thing I do is produce an executable file written in that language (it could be a compiled program or a script) that when run prints 'hello, world' and a newline to stdout:
theironknuckle#beastbook:~/Code$ ./hello
hello, world
After about an hour of mucking around with GNU Smalltalk, I haven't found out how to do this.
(I know that the hello world program can be expressed from within a session as
'hello, world' printNl
This doesn't meet my stdout requirements)
I understand that there's no mainline in Smalltalk. So I'm quite intrigued by what sort of boilerplate could possibly be necessary to make it happen. Again, the file doesn't necessarily have to be compiled, but the end result of the exercise has to be smalltalk code that results in the above session extract.
PS. yesyesyes I know that I'm doing it wrong by not embracing the "image based programming" philosophy. I don't care. I'm not against learning how to work with the image and IDE and all that, but I really have minimal interest right now. What I care about is the Smalltalk language itself. Syntactically, philosophically and typographically it is rather beautiful. I feel comfortable learning programming languages from a commandline interpreter and a text editor. :)
In GNU Smalltalk, there's pretty much no boilerplate.
You could just put your single line in a .st file, and run it with gst hello.st
If you want to explore using a class instead of directly executed statements, then that's easy too, the following in a file passed to gst will do the trick:
Object subclass: Hello [
greet [
'Hello, World' displayNl
]
].
greeting := Hello new.
greeting greet.
Files passed to gst on the command line are parsed and executed in sequence, so you could split the above listing into two separate files - one to declare / compile the class, and the second to actually run it.
Once you've developed your program, you can use the -S flag to gst to snapshot the image after loading your classes, so that you don't have the compilation overhead each time, and can just run your startup statement instead.
gst also has shebang support, so you can put #! /usr/bin/gst -f at the top of your file if you don't want to pass it to gst manually. (See the documentation on invocation for more, including how to do it without hardcoding the location of gst)
Related
I'm a user of the Ruby language, and while the idea of using the Crystal language as a one-liner may be silly, the Crystal language is so fast that even when you add up the compile time, it can sometimes run faster than writing one-liners in Ruby. Is there a way to do one-liners in Crystal?
It can, but its definitely not written with that in mind like Perl and to some degree Ruby.
This is mostly down to Crystal intentionally not inheriting many of the Perlisms that makes this so convenient in Ruby, such as the -p, -n etc command line flags and globals like $_, $' etc.
Other than that, nothing stops you from running crystal eval 'some code' to your heart's content.
Yes, it definitely is not only possible but very easy. I have never used Crystal before in my life, and I was able to create a one-liner in less than 5 seconds:
puts "Hello, World!"
I am trying to read (and eventually set to a Make variable) the value of a variable set in a TCL script in order to echo it to a file.
(I know I can simply puts the var to the file, but it's a more complicated flow, and doing it in the Make would be easier. Just want to know if this is possible)
Set final_val "Test finished! No Failures"
I then want to use the value of final_val (set in the TCL) in the Makefile that calls the script:
#file.tcl
#echo final_val >> $(out_file)
P.S. I am on TCL 8.5
It's not trivial to get a value in a Tcl script into a make run. The simplest way might be to arrange for the script to produce that variable as its only output, as you can then use a fairly simple approach:
On the Tcl side:
#!/usr/bin/env tclsh
set final_val "Test finished! No Failures"
puts $final_val
On the Make side (assuming you've made everything executable):
FINAL_VAL := $(shell thescript.tcl)
There's a lot more complexity possible than just this, of course, but this is the simplest technique that could possibly work.
If you're producing a lot of output in that script, you might need to instead use a separate post-processing of the output to get the part you want. That can get really complex; those cases are often better off being converted to using intermediate files, possibly with recursive makes, as you don't really want to have significant processing done during the variable definition phase of processing a makefile (as it causes real headaches when it goes wrong, and puts you in a world of pain with debugging).
One way that's more complex but which works really well for me is to make the Tcl code generate some file, perhaps outputinfo.mk, that contains the make variable definitions that I want. (On the Tcl side, you're just writing to a file. There's loads of ways to do that.)
Then, I'd make the main makefile have a dependency rule that says that you generate outputinfo.mk you need to run the Tcl script, and then say that the makefile wants to include that outputinfo.mk:
outputinfo.mk:
thescript.tcl > outputinfo.mk
include outputinfo.mk
(For the sake of argument, I'm assuming here that the script writes the file contents to stdout with puts.)
This works well, since make knows about such dependencies caused by include and does the right thing.
I'm trying to create a Ruby command line interface with the following options:
ruby cli.rb -g # Prints a list of people sorted by gender
ruby cli.rb -n # Prints a list of people sorted by last name
ruby cli.rb -b # Prints a list of people sorted by birth date
ruby cli.rb -a LastName FirstName DateOfBirth # Add a new person to the list of people
I have already created a Directory class that stores a list of people and also has methods to sort people and add people. The next step is to build a CLI around this class.
How can I create this in a way that can be tested with RSpec? My initial attempt involved a looped gets.chomp instead of running a Ruby file with flags, but this loop does not play well with RSpec. The examples I've found online just use Ruby's OptionParser in a simple script and not inside an actual class. Also, how would I handle creating ARGV parameters in RSpec? I'm just looking for tips on the general structure of this CLI class so that I can write tests.
I do not want to use any gems for this.
I'm not sure what the context of your problem is, so I'm just going to give you a little brain dump, the merit of which is yours to determine:
A cold hard fact: In the wild, I've seen few people write unit tests for command line arguments. The reason for this probably has to do with the fact that a well-written command line tool is a lot like a very skinny router (in the MVC sense). It looks at the arguments, and routes them to the proper function (eg, "-g" routes to something like MyObject.print_by_gender). And if you use a battle-tested options parser (like OptionParser) on the incoming side and a well-tested piece of code that the router calls (eg, MyObject.print_by_gender, assuming that's the name of a function, and that you've tested it well), then there's very little to test in the command line file itself.
That context in place, let's consider your problem. You want to test an object that interacts with the external world in 2 ways. Namely, stdin and stdout. This means that you could create an integration-style test, and actually pass thing in on stdin and test the output the command creates on stdout - as you mentioned - or you can mock stdin and stdout. In my experience, mocking external things like stdin and stdout are a better approach. That said, I'll recommend these two SO questions/answers to explain how to mock STDIN (this and this).
The scala documentation shows that the way to create a scala script is like this:
#!/bin/sh
exec scala "$0" "$#"
!#
/* Script here */
I know that this executes scala with the name of the script file and the arguments passed to it, and that the scala command apparently knows to read a file that starts like this and ignore everything up to the reversed shebang !#
My question is: is there any reason why I should use this (rather verbose) format for a scala script, rather than just:
#!/bin/env scala
/* Script here */
This, as far a I can tell from a quick test, does exactly the same thing, but is less verbose.
How old is the documentation? Usually, this sort of thing (often referred to as 'the exec hack') was recommended before /bin/env was common, and this was the best way to get the functionality. Note that /usr/bin/env is more common than /bin/env, and ought to be used instead.
Note that it's /usr/bin/env, not /bin/env.
There are no benefits to using an intermediate shell instead of /usr/bin/env, except running in some rare antique Unix variants where env isn't in /usr/bin. Well, technically SCO still exists, but does Scala even run there?
However the advantage of the shell variant is that it gives an opportunity to tune what is executed, for example to add elements to PATH or CLASSPATH, or to add options such as -savecompiled to the interpreter (as shown in the manual). This may be why the documentation suggests the shell form.
I am not on the Scala development team and I don't know what the historical motivation for the Scala documentation was.
Scala did not always support /usr/bin/env. No particular reason for it, just, I imagine, the person who wrote the shell scripting support was not familiar with that syntax, back in the mid 00's. The documentation followed what was supported, and I added /usr/bin/env support at some point (iirc), but never bothered changing the documentation, it would seem.
Do you know if there's any tool for compiling bash scripts?
It doesn't matter if that tool is just a translator (for example, something that converts a bash script to a C program), as long as the translated result can be compiled.
I'm looking for something like shc (it's just an example -- I know that shc doesn't work as a compiler). Are there any other similar tools?
A Google search brings up CCsh, but it will set you back $50 per machine for a license.
The documentation says that CCsh compiles Bourne Shell (not bash ...) scripts to C code and that it understands how to replicate the functionality of 50 odd standard commands avoiding the need to fork them.
But CCsh is not open source, so if it doesn't do what you need (or expect) you won't be able to look at the source code to figure out why.
I don't think you're going to find anything, because you can't really "compile" a shell script. You could write a simple script that converts all lines to calls to system(3), then "compile" that as a C program, but this wouldn't have a major performance boost over anything you're currently using, and might not handle variables correctly. Don't do this.
The problem with "compiling" a shell script is that shell scripts just call external programs.
In theory you could actually get a good performance boost.
Think of all the
if [ x"$MYVAR" == x"TheResult" ]; then echo "TheResult Happened" fi
(note invocation of test, then echo, as well as the interpreting needed to be done.)
which could be replaced by
if ( !strcmp(myvar, "TheResult") ) printf("TheResult Happened");
In C: no process launching, no having to do path searching. Lots of goodness.