Does anyone know of a scripting language that's included with most platforms (say Mac/Windows/Linux)? I haven't been able to find one. So far javascript in web browsers or compiled java are about it. Jython comes close.
My goal is to be able to download a file from the web or portable storage and just run it, without having to install something first, or have special user permissions, or edit it, or rename it, or give it executable privilages. It would give you access to generally accepted metaphors in computing: input, output, persistent storage, time, spawning tasks, sockets, fixed and floating point math, unicode, etc. Ideally it would abstract away minutia like line endings, endianness, and yielding for other processes.
I don't want to get into why having a universal language/virtual machine is important, or at the very least, useful. I feel that we are missing a middleware above the operating system level, something like POSIX but less esoteric, and without it, we all are forced to spend a disproportionate amount of time reinventing the wheel or writing special cases. For me, availability and a complete feature set are more important than speed (which could come later).
Thanks in advance for any insights you can provide,
Zack Morris
You will be able to run carefully written sh scripts on almost all unix systems.
If you want to add Microsoft systems, then it is more difficult, but still possible to provide a single script file, that will "autodetect" the interpreter it's running on and select between a sh part and a command.com or whatever they have on Microsoft systems.
Once you can run a script on a known system you can further download or unpack and install automatically whatever software you need.
Related
Is it possible to compile a swift binary from an OS X computer so that it runs on a server running Linux as a single binary without no extra libraries that need to be dynamically linked?
I'm thinking something like passing a -target to the swift command and passing another parameter to let it statically link all dependencies, but I'm not sure what the exact commands are.
The exact value for -target seems to be rather elusive.
Do I need to know the exact target distribution to be able to pass the correct string to the -target parameter?
From reading the sources on github
target would be Linux
machine would be x86_64
This gets called by the primary build script
This how ever answers a part of the question
The exact value for -target seems to be rather elusive.
Install a GCC toolchain for Mac OSX that can retarget Linux, one repo that I can see is OSXCross, for example.
Supply the values to the environment variables to GCC prior to running the script, that references that toolchain.
Unfortunately, that does not guarantee it will work, but give it a try and see what happens.
Is it possible to compile a swift binary from an OS X computer so that it runs on a server running Linux as a single binary without no extra libraries that need to be dynamically linked?
The short answer? Of course it is! Anything is possible when you put your heart to it!
Is it efficient? Inherently, no.
While I'm sure everyone here is familiar with what a compiler does, for the sake of this question and its newest of users, a compiler is an application that converts human readable code and maps it to a binary format that a computer can understand. However it should be worth mentioning that not all computers are the same. Each computer operating system has a different binary mapping than the other so a simple operation like copying values could be expressed as 1010 on one machine, and 0101 on another. As stated before in many questions prior, and for example this one, many programming languages are buildable across a variety of machines, but very few of them are portable across them because each computer has a different binary mapping.
~~~~~~~
So how do we fix this?
~~~~~~~
Well there are a number of solutions to fix this. The most obvious
method is to simply make your environment the target environment and
build your program to your hearts content. You obviously already did
this through a virtual machine and this typically what many
developers will do. This is by far the easiest solution but it
defeats the purpose of the question where you want to simply build
from your OSX machine.
Earlier you said you heard people talking about compiling windows programs on linux machines. Cygwin is a a development platform aimed at obtaining the windows framework that is not normally present on linux machines and allows many programs to be built with the windows framework in mind. However all its doing is adding binaries so that the compiler has some proper places to map to when windows only commands are found within a configuration. All its doing is introducing the binary configurations necessary for a program to successfully be ported over. This ties into the second option.
Secondly comes a compiler that supports cross platform compilation.
While I am currently uninformed and/or unfamiliar with such
compilers, this is technically a valid solution but would I call it
reliable? Probably not. If anything you're just adding more work to
your compiler as not only does it have to correctly map the syntax of
one computer program for one computer, it has to waste time linking
it to the new binaries. Additionally you would need to have the
compiler remember these linking's which could entail more wasted
memory space for having this one compiler.
Even then, systems like these are few and far between and whether its guaranteed to work depends upon how well the compilers maintainer knows their stuff, how frequently they update it etc. etc. And the chances that they even performed to correct mappings of binaries in the first place is not something I'd stake my life on.
The third and perhaps most ideal solution is to look into container technologies such as docker. Their containers are essentially ways for you to build your app and port it to new machines without having to change or modify anything about how you build and compile it. Simply build one, store it in a container, port it to your machine of choice and integrate it into your current project. Come to think of it, container systems like docker were built to prevent the very thing that you are currently experiencing, where you have a source code working on your one machine but no place else. Something like docker will be able to run your code on any machine without having to recompile it for each new machine.
Docker provides an interesting framework for container to container communication, application examples and has a fairly straightforward documentation that it would be worthwhile to look at to see if your project could have some of its parts ported to docker.
This being said, there are multiple ways to fix the issue you are currently facing, so as you being a software engineer, its up to you in what would be the most ideal way of handling your project.
// EDIT //
Will edit this to be a better response once im not drop-dead tired.
I've built a set of tools I use in my day-to-day work and I would like to make them look a bit more "professional" in order to sell them to financial institutions.
At the moment these tools are written in Perl and are executed from a DOS command line, it's extremely efficient but it doesn't look very attractive.
So, I would like to add a user interface to it but I don't really know what to use for language knowning that :
A Perl CGI interface hosted on the web is not an option since the information to be given as input is quite sensitive.
It would be ideal to sell it as a package/executable.
I don't really like the Perl/Tk interface.
I'm ok with rewritting the application in another language but I would prefere to reuse the main modules in Perl since it's very powerful with regular expressions and lists/arrays.
What would you advise me to do ?
Thanks,
Lory
If you want a non-web-based GUI, and don't like Tk, there's also Wx, which is a wrapper for the wxWidgets GUI toolkit.
However, web applications nowadays can be really easy to create (using a modern framework). Take a Mojolicious application, for example: Mojolicious carries no dependencies other than Perl 5.12.x, and provides its own web server (Hypnotoad). You can start by generating a "Lite::App", which is a simple self-contained single-file application, and then grow it to a bigger distribution later on as the need arises. It even comes with tools to convert your application to a conveniently packaged distribution that can be installed as easily as any CPAN module.
So that leaves the issue of security. User authentication, IP whitelisting, local network only... there are many ways to make a web application "for internal use only" if that's what you need.
You might just throw together a web-application prototype, and once you determine customer interest in your product, invest the substantial time in writing it as a Windows GUI application.
Continuing on from DavidO's answer, because the current web microframeworks for Perl (I prefer Dancer over his suggestion of Mojolicious, but both are good and largely equivalent) contain their own bundled web mini-servers, they also allow for the app to easily run entirely on the local machine.
Since these mini-servers default to a non-standard port (usually 3000 or 5000) by default and you can easily set them to a different port, they can be isolated by firewalls relatively easily, ensuring that nobody can connect to them remotely. You can also, of course, include and IP address check in the app and have it reject any requests that don't originate from localhost.
My guess is that the target system will be Windows. Use a RAD (Rapid Application Development) platform to develop a GUI. Examples for such a platform are Delphi or .NET with C# or VB. For bundling the Perl part, consider using a tool called perl2exe.
It doesn't sound like your scripts should require a web server. Also, consider the installation hassle. Only guessing as you're not giving much information about what your scripts are doing.
I am using the Cava packager to deploy my Perl-written tools. You can even generate an installer executable with just some mouse-clicks. It works pretty well with strawberry Perl and wxPerl on Windows.
I work in a project that uses Perl scripts on machines that are maintained by system folks, and installing packages such as Perl modules is no easy task - you usually have to call the person with the permissions to do that, wait several days, learn the API of the package, and then remember to install it on every newly configured machine ever installed.
The alternative that is many times chosen is just calling system() (or backtick notation, ``, inside Perl) and using the output of the shell command that does what you want. Of course it's not always possible, and when it use, there is usually a wrapping to do around the command call, but it's generally easier.
My question is when is the trade-off pulling towards either side, in your experience?
Edit: adding an example:
I want to print the total size of a directory in a human-readable format, or list all regular files bigger than a certain size, and du seems to make this easier than installing modules that do the same thing...
Oh, that's an easy one. One always prefers modules because the tighter integration makes it possible to pass around data that do not suit the traditional IPC.
What, did you expect help in rationalising your suffering under crappy sysadminship?
The core issue seems to be the perceived difficulty and length of time to install Perl modules. I would identify why they have problems installing the packages and try and help streamline their process.
A common solution is to modify your process. Admins don't typically like to install straight from CPAN, but as a developer you can use a local CPAN repo. You "freeze" the packages you use there, and then promote them for use in production.
That said the trade-off between using modules or shelling it out as follows:
Data
Modules typically return structured data, shelling out returns unstructured text that you have to parse.
Performance/Resource Usage
Shelling out creates a whole other process, modules usually provide functionality within the current operating process.
Additional Dependencies
Shelling out makes your program dependent on whatever you're shelling out to. Keep in mind that some basic programs change in output and behavior from OS to OS, so you may also be coupling yourself to a particular OS or set of OSes.
Modules, always modules. And, when I say always, I mean "almost always."
Modules are easier to control and to debug. It's easier to require a module be installed than some unrelated utility. It's more portable to use a module than to rely on the chancy command line syntax of a particular command.
You have a bunch of modules that go with the core distro. Just use them.
You can install modules right in your home directory and when the time comes negotiate with the sysadmins: http://perl.jonallen.info/writing/articles/install-perl-modules-without-root
As said above, always modules, because ls ain't dir...
Question
What would be a good (ideally, technical) reason to ever program some non-trivial task in dos batch language on a modern Windows system as opposed to downloading either PowerShell, or ActiveState Perl?
To be more specific, I make the following two assumptions for the duration of this question:
anyone technical enough to be able to write a medium-complexity batch script is technical enough to install either of the scripting interpreters.
Neither of those two present enough of a learning curve for basic batch replacement tasks that said curve would outweigh the pain of doing any remotely-non-trivial task in batch.
Notes
"You need a batch program for autoexec.bat" is not a valid reason. Your autoexec.bat may consist of simply calling non-batch script.
If you disagree with either of my 2 assumptions above, that's fine, and I may be wrong. But my question is specifically "assuming those 2 assumptions are correct, what would be the reason to still stick with batch?" If it makes it easier to suspend disbelief (in case you disagree with me), add in a 3rd assumption that the question is limited to people who already posess at least some modicum of PowerShell or Perl experience.
To re-iterate - this is not meant to be a subjective question about how easy it is to learn PSh or ASPerl compared to doing advanced batch coding. That is a separate question that is too subjective to be bothered with in this post.
Background:
I used to do some fairly complicated batch programming back in the elder days, and remember batch as one of the worst possible programming languages I had encountered.
The idea for this question came after seeing a bunch of batch questions on SO, and trying to grok the answer of one of them out of sheer curiosity and giving up in pain after a minute, exclaiming mentally "why would anyone go through this pain instead of doing that in 1 line of Perl?" :)
My own plausible answer
I assume there may be an an likely DOS-compatible system, which has DOS interpreter but has no compatible PowerShell or Perl... I'm not aware of one but not completely impossible.
Typically, the rationale is that you need the script to run on a machine which does not have another interpreter and on which you are not allowed to install an interpreter. Production servers in many companies are a good example -- you want them to have as few exploitation vectors as possible, which means no scripting languages that are not required for application functionality.
You're right when you say that the batch language is a terrible language -- there's a reason they sunk the time and money into building PowerShell -- but it's also the only universal language you can rely on across the myriad versions of Windows.
Because I work at a bank where the default browser is IE6 on Windows XP and I have no idea if I'll be able to install PowerShell on someone's computer and I have a batch file which they can use to quickly and easily:
sqlcmd with some pre-import SQL
bcp
sqlcmd with some post-import SQL
With the whole batch needing to be RUNAS /NETONLY because the workstation does not participate in the domain that the SQL Server is on/trusts.
Not that I'm complaining or anything...
And I would say they are non-trivial because sometimes they take parameters and they require some pretty crazy escape quoting.
I have a contract at a major utility company which absolutely does not allow unapproved programs on their computers. That would be expected of computers attached to the innermost networks which connect between control computers and devices, but the ban applies to the general purpose and administrative networks too.
The approved operating system is Windows XP SP3 with IE6. Upgrading is not allowed until technical support blesses it. Which, it seems, still may be some years from now.
Therefore, batch files are the only general scripting tool available. Some developer machines have access to C++ compilers, but the resulting programs are not permitted for internal distribution until the conclusion of a (probable multi-year) validation effort.
You could also choose to use vbscript or jscript rather than perl and you wouldn't need to worry about installing any additional software.
various reasons
Its company policy, be it for security or other illogical reasons given by management, that you strictly
use DOS.
You had to support some legacy DOS
scripts already written.
You or the admins in the company
only know DOS and have no capacity
to learn other languages.
You are coding for part of a larger
DOS program already written
Doing things the "harder" way make you look
cool.
You have a lot of time on your hands
to devise workarounds for some
things that are difficult to do
easily with DOS
I'm not planning on doing this right now, as I don't have the experience in this area to even attempt it at the moment, but I'm curious about something.
If implementing an operating system from scratch, what would it take to build an application like VirtualBox? Not necessarily as user friendly with a nice GUI or anything, but something that is capable of launching other operating systems and allowing you to interact with them?
I've got an idea rolling around in my head about an operating system that uses virtualization for a few key things (probably ideas out there like this already), and I'm just curious what it would take to build it.
There is a version of VirtualBox that is open source. If you want to know what it would take, checking out their source would be a very good start. Also, check out Xen (open source as well).