Is there a way to build CLI with no dependencies required? - ruby

Recently I though about scaffolding a little CLI with Ruby, but was concerned about using it on a machine with no Ruby installed. I've searched for examples of popular CLI's and found that Docker CLI is built with Go language. I'm able to use this CLI on my computer with no Go installed. How can one build a tool that will not require you to install Ruby?
My guess is that there's a build process involved and it might be compiled to something present on most systems, like shell or smth. Sorry if this is a lame guess/question!

(note: this is not a detailed answer, just a summary of how it works)
Cli programs are just as other programs, there is nothing special about them.
Go is a compiled language - a program called "compiler" takes the go code and translate it directly to machine language, following the conventions imposed by an operative system. It becames pure 0 and 1, no references to anything else. The main advantage is that is self-contained, but you have to recompile it on every different architecture (32bit, arm processors, ...) and operating system (windows, linux, macos) - it's the operating system that take cares of redirecting input and output on cli.
Ruby, instead, is interpreted. There is a program called "Ruby interpreter" which translates your code to the appropriate machine code on the fly. It's a different approach, it's more "high level".
The advantage is that you don't need to recompile the code. However, the "Ruby interpreter" itself must be written in some compiled language.

Related

Tcl tclsh Set Up

I am just starting out in Tcl and am trying to properly configure an editor and interpreter for use. On Tcl's download page it is recommended to use ActiveState's ActiveTcl, but I am learning Tcl for possible production use and want to avoid paying for it.
I tried setting up Eclipse's DLTK to use for learning, but from what I found I need to direct it to the tclsh executable to use it as the interpreter. In Tcl version 8.6.6, I can't find anything that will work. The supposed formats (I'm on Windows) should follow what's seen here, as I've seen this a few examples/tutorials.
As a last resort, I tried following the Windows instructions here to use my MS Visual Studio 2015 work with this, but there is no such vcvars file (what's asked for when reading makefile.vc after downloading Tcl).
I would really like to use Eclipse for this, so I guess my question is as follows: How do you use tclsh as a Tcl interpreter in Tcl 8.6.6?
ActiveTcl isn't a pay-for product. (ActiveState have some of those, but their language distribution isn't one of them as long as you're not after a support plan.)
To configure Eclipse to use the right installed version of Tcl, go to the Tcl → Interpreters page in the main Preferences panel. That lets you Add… an interpreter, which essentially just requires you to find where the tclsh you want to use is on your filesystem, and to give it a name. I use names like “Tcl 8.6” in my installation, so it isn't exactly rocket science. The DLTK system can find out pretty much everything else once it knows where the interpreter implementation is, but if you have several set up (e.g., I have both 8.5 and 8.6) then you'll need to say which one is default using the checkboxes in the list in the Interpreters pane.
(I've verified the above against Eclipse Neon running on OSX, but I don't think it will vary very much with other versions or platforms.)

What is the difference between "binary install" and "compile and install from source"? Which is better?

I want to install a driver for Ros (robot operating system), and I have two options the binary install and the compile and install from source. I would like to know which installation is better, and what are the advantages and disadvantages of each one.
Source: AKA sourcecode, usually in some sort of tarball or zip file. This is RAW programming language code. You need some sort of compiler (javac for java, gcc for c++, etc.) to create the executable that your computer then runs.
Advantages:
You can see what the source code is which means....
You can edit the end result program to behave differently
Depending on what you're doing, when you compile, you could enable certain optimizations that will work on your machine and ONLY your machine (or one EXACTLY like it). For instance, for some sort of gfx rendering software, you could compile it to enable GPU support, which would increase the rendering speed.
You can create a version of an application for a different OS/Chipset (see Binary below)
Disadvantages:
You have to have your compiler installed
You need to manually install all required libraries, which frequently also need to be compiled (and THEIR libraries need to be installed, etc.) This can easily turn a quick 30-second command into a multi-hour project.
There are any number of things that could go wrong, and if you're not familiar with what the various errors mean, finding support online could be quite difficult.
Binary: This is the actual program that runs. This is the executable that gets created when you compile from source. They typically have all necessary libraries built into them, or install/deploy them as necessary (depending on how the application was written).
Advantages:
It's ready-to-run. If you have a binary designed for your processor and operating system, then chances are you can run the program and everything will work the first time.
Less configuration. You don't have to set up a whole bunch of configuration options to use the program; it just uses a generic default configuration.
If something goes wrong, it should be a little easier to find help online, since the binary is pre-compiled....other people may be using it, which means you are using the EXACT same program as them, not one optimized for your system.
Disadvantages:
You can't see/edit the source code, so you can't get optimizations, or tweak it for your specific application. Additionally, you don't really know what the program is going to do, so there could be nasty surprises waiting for you (this is why Antivirus is useful....although LESS necessary on a linux system).
Your system must be compatible with the Binary. For instance, you can't run a 64-bit application on a 32-bit operating system. You can't run an Intel binary for OS X on an older PowerPC-based G5 Mac.
In summary, which one is "better" is up to you. Only you can decide which one will be necessary for whatever it is you're trying to do. In most cases, using the binary is going to be just fine, and give you the least trouble. Sometimes, though, it is nice to have the source available, if only as documentation.

How do I write a cross platform installer script?

Instead of having a different download of a program for Windows and Linux, would it be possible to make the download be a cross-platform script/executable that can download the correct installer from an FTP server and start that? What language should I write it in? The only one I can think of would be Java, but I don't want to take the time to learn it. I can't write it in Python or BASH, because most Windows machines don't have these installed. How should I do this?
Cross-platform executable(like an exe or a.out or ELF) is out of question. An executable is never cross-platform when Windows is involved. The scripting languages(or JIT compiled) have to be brought in for this purpose. We are in a CHICKEN-AND-EGG paradox. You may have to detect the OS the downloader is using, using a Javascript script in your website page and decide on what is to be done next etc...
Although not exactly what you are looking for, below are some pointers.
The best tool I know of, for multi-platform installers, is Flexera Software's InstallAnywhere. That might be a bit costly. For free options I would look into options like:
PERL
PYTHON (but this is out of question as per your post, but look at the end of my post for more options for Python)
Although writing the installer in any of the above languages might mean a lot more work, they provide you unmatched flexibility and complete control.
Perl requires that you install Perl interpreter and modules on Windows. But this also seems to be out of question for you. So you may avoid the headache by looking into:
PAR
pp
For Python go through:
py2exe
pyinstaller

Portable scripting language for a multi-server admin?

Please Note: Portable as in portableapps.com, not in the traditional sense of a language that can be used on multiple architectures or operating systems. Whoever coined this usage of the word portable should be whacked. :)
I'm a DBA and sysadmin, mostly for Windows machines running SQL Server. I'm looking for a programming/scripting language for Windows that doesn't require Admin access or an installer, needing no install process other than expanding it into a folder. My intent is to have a language for automation around which I can standardize.
Up to this point, I've been using a combination of batch files and Unix shell, using sh.exe from UnxUtils but it's far from a perfect solution.
I've evaluated a handful of options, all of them have at least one serious shortcoming or another. I have a strong preference for something open source or dual license, but I'm more interested in finding the right tool than anything else. Not interested that anything that relies on Cygwin or Java, but at this point I'd be fine with something that needs .NET.
Requirements:
Manageable footprint (1-100 files, under 30 MB installed)
Run on Windows XP and Server (2003+)
No installer (exe, msi)
No reliance on a JVM or Cygwin install
Works with external pipes, processes, and files
Support for MS SQL Server or ODBC connections
Bonus Points:
Open Source
FFI for calling functions in native DLLs
GUI support (native or gtk, wx, fltk, etc)
Linux, AIX, and/or OS X support
Dynamic, object oriented and/or functional, interpreted or bytecode compiled; interactive development
Able to package or compile scripts into executables
So far I've tried:
Ruby: 148 MB on disk, 23000 files
Portable Python: 54 MB on disk, 2800 files
Strawberry Perl: 123 MB on disk, 3600 files
REBOL: Great, except closed source and no MSSQL or ODBC in free version
Squeak Smalltalk: Great, except poor support for scripting
I urge you to try Lua. Regarding your requirements:
Tiny footprint (56 source files, under 150K compiled)
Runs everywhere (uses only ANSI C)
No installer needed; you compile from source (there's also a "batteries included" package that I haven't explored
Doesn't need JVM and works with any ANSI C compiler, so you can compile with Visual Studio, not Cygwin
Works with external processes and files but only to the extent supported by ANSI C. If POSIX popen is provided then that is supported also.
And your bonus points:
Open source (MIT license)
FFI to C is brilliantly conceived and executed—not quite as simple as Tcl but loads more powerful. Much better integration with C than Python or Ruby.
GUI support is mixed but there are good bindings for wx widgets. QT support was there at one time but I don't know if it has been maintained.
Linux is supported
Language/compiler features:
Dynamic
Functional
Prototype-based objects and inheritance through metamethods (you'll want to see examples in the book below
Fastest bytecode compiler in the West
Interactive read-eval-print loop; load new code dynamically
Able to package scripts into executables; either use Luiz de Figueiredo's srlua, or I can send you a 120-line Lua script that converts Lua source to a .c file that you link in with your app and the interpreter to make an executable.
Additional bonus points:
Very crisp, clean, well-designed language.
Small enough to master in its entirety and to be productive within a day.
Superb book Programming in Lua (check out the previous edition free online)
There are a couple of options for Python that might fit your bill:
The first is IronPython, which can be run without an installer and will play nicely with .net APIs. This gives you access to anything with a .net API or a COM typelib that you could build a PIA for. I've used at as a scripting mechanism for precisely this reason - it could be dropped into a directory within the system and did not need to be explicitly installed..You will have to have an appropriate .Net runtime installed, but .Net 2.0 is installed with SQL Server 2005. SQL Server can be accessed through ADO.net and building GUIs with Winforms is fairly straightforward.
The second is Portable Python which is designed to be run off a USB key. Although I see you've already tried it, you might elaborate on what the shortcomings were. If something isn't available in the basic install you could always look into building a custom version with it included. TkInter (at least) is bundled.You can also use Py2EXE to generate standalone python applications with all superfluous junk stripped out. This will give you about 10 files or so (depending on the number of DLLs) that can be run from a single directory, possibly on a USB key.
Running local python installs on Unix-oid OS's is pretty straightforward, so that's pretty much a no brainer. Also, python comes with most linux distros and is available as 'contributed software' from most if not all trad unix vendors. IIRC it's also bundled with MacOS.
Tclkit is a single-file, self-contained Tcl/Tk system. The mac version I have is about 3.8 megs. You can get a version for just about any modern OS. I carry around a thumb drive that has mac, windows and linux binaries so I can run my scripts on any platform. No install is required, just copy one file wherever you want.
The only thing it's missing from your original spec is MS SQL Server / ODBC support out of the box. I know people use tcl for that but I think you'll have to add an extra library or something. See the Tcl'ers wiki entry on MS SQL Server for more information.
For tcl, apart from Tclkit, freewrap is another small portable, self-contained interpreter for tcl.
Just rename the freewrap executable to something else will convert it to a stand-alone interpreter. Renaming it back to freewrap will convert it to a script wrapper.
Also, freewrapped apps contain a tcl interpreter. In dire emergencies you can try opening the app as a zip file and edit/replace the tcl code contained within (just remember to make a copy first). This has saved me several times when I'm at a client site without development tools but need to troubleshoot something. I just make a copy of one of my deployed app and presto - instant development environment!
Looking at wikipedia's exhaustive list of portable software
There's Tiny C compiler, again on Wikipedia here, and its own homepage here.
To summarize by quoting from wikipedia's list of features:
Small - can compile and execute C code everywhere, for example on rescue disks (about 100KB for x86 TCC executable, including C preprocessor, C compiler, assembler and linker).
Fast - tcc generates optimized x86 code. No byte code overhead. It compiles, assembles and links about 9 times faster than GCC.
Any C dynamic library can be used directly. TCC is heading towards full ISOC99 compliance. TCC can of course compile itself.
Includes an optional memory and bound checker. Bound checked code can be mixed freely with standard code.
Compile and execute C source directly. No linking or assembly necessary. Full C preprocessor and GNU-like assembler included.
C script is supported: just add '#!/usr/local/bin/tcc -run' at the first line of your C source, and execute it directly from the command line.
With libtcc, you can use TCC as a backend for dynamic code generation.
Few dependencies. It includes its own hand-written lexer, and it is implemented using a recursive descent parser. Thus, building TCC requires few other libraries.
Its LGPL license permits anyone to use, modify, and/or redistribute the software, and it can be used to develop either open source or proprietary software.
Hope this helps and would be of use,
Best regards,
Tom.
Every somewhat modern Windows version comes pre-installed with both VBScript and JScript. The doesn't meet all your features (compile to an executable comes to mind), but they certainly have an unbeatable advantage with the installation size: it's hard to beat 0.
In addition to the Lua suggestion, there is also Idle. It is basically a superset of Lua 5.1, with both the language (and libraries) and the implementation based on Lua. It was originally created to be a more complete scripting solution for Windows: because Lua is primarly intended for embedding, it has a rather small standard library and it is usually expected that the embedding application provides a rich library to Lua.
This makes sense for an embedded language, because, after all, there isn't much common functionality between, say Adobe Lightroom, Nginx and World of Warcraft, so there simply is nothing you can put in a standard library. But for a more general purpose OS scripting language, one would want a slightly larger library. Thus, Idle bundles a couple of libraries that are third-party (and sometimes hard to get to work on Windows) in Lua in its standard library.
Some of the things that the Idle standard library adds over Lua are tight Win32 integration, SQLite3 support, networking support, a PEG parser generator and archive support.
Also, Idle has support for embedding Perl and C code into your Idle programs.

Erlang compilation - Erlang as stand alone executeable

is there a way to compile Erlang to be a stand-alone executable?
this means, to run it as an exe without the Erlang runtime.
While it's possible to wrap everything up in a single EXE, you're not going to get away from having an Erlang runtime. Dynamic languages like Erlang can't really be compiled to native x86 code, for instance, due to their nature. There has to be an interpreter in there somewhere.
It's possible to come up with a scheme that bundles the interpreter and all the BEAM files into a single EXE you can double-click and run directly, but that's probably more work than you were wanting to go to. I've seen it done before, but there's rarely a good reason to do it, so I won't bother going into detail on the techniques here.
Instead, I suggest you use the same technique they use for Python's py2exe and py2app programs for creating Windows and Mac OS X executables, respectively. These programs load the program's main module up into a Python interpreter, figure out which other modules it needs using the language's built-in reflection mechanisms, then write out all those compiled modules along with a copy of the language interpreter and a small wrapper program that launches the program's main module with the interpreter. The directory containing those files is then a stand-alone environment, having everything needed to run the program. The only difference in the Erlang case is that python.exe becomes erl.exe, and *.pyc becomes *.beam. The basic idea is still the same.
You can simplify this if you don't need it to work with any arbitrary Erlang program, but only yours. In that case, you just copy the Erlang interpreter and all the .beam files that make up your program into a single directory. You can make this part of your program's Makefile, for instance.
You can then use your favorite setup.exe or MSI creation method for creating a distributable package that installs this collection of files into c:\Program Files\MyProgram on the end user's system and creates a shortcut for "erl mainmodule.beam" in their Start menu. The end user doesn't care that as part of the program they also get a copy of Erlang. That's an implementation detail.
you can use Warp. I've added examples for wrapping an Erlang release.

Resources