Last year I wrote a post about being a computational survivalist, someone able to get their work done with just basic command line tools when necessary. This post will be a different take on the same theme.
I just got a laptop from an extremely security-conscious client. I assume it runs Windows 10 and that I will not be able to install any software without an act of Congress. I don’t know yet because I haven’t booted it up. And in fact I cannot boot it up yet because I don’t have the badge yet to unlock it.
If being able to work with just default command line tools is like wilderness survival, being able to work with only consumer software is like urban survival, like trying to live in an abandoned shopping mall.
There must be some scientific software on the laptop. I imagine I may have to re-implement from scratch some tools that aren’t installed. I’ve been in that situation before.
One time I was an expert witness on a legal case and had to review the other side’s software. I could only work on their laptop, from their attorney’s office, with no network connection and no phone. I could request some software to be installed before I arrived, so I asked them to put Python on the laptop. I could bring books into the room with the laptop, so I brought the Python Cookbook with me.
If you don’t have grep, sed, or awk, but you do have Perl, you and roll your own version of the utilities in a few lines of code. For example, see Perl as a better grep.
I always use LaTeX for writing math, but the equation editor in Microsoft Word supports a large amount of LaTeX syntax. Or at least it did when I last tried it a decade ago.
The Windows command line has more Unix-like utilities than you might imagine. Several times I’ve typed a Unix command at the Windows cmd.exe prompt, thought “Oh wait. I’m on Windows, so that won’t work,” and the command works. The biggest difference between the Windows and Linux command lines is not the utilities per se. You can install many of the utilities, say through GOW.
The biggest difference in command lines is that on Windows, each utility parses its own arguments, whereas on Linux the shell parses the arguments first and passes the result to the utilities. So, for example, passing multiple files to a utility may or may not work on Windows, depending on the capability of the utility. On Linux, this just works because it is the shell itself rather than the utilities launched from the shell that orchestrates the workflow.
I expect this new project will be very interesting, and worth putting up with the minor annoyances of not having my preferred tools at my fingertips. And maybe it won’t be as hard as I imagine to request new software. If not, it can be fun to explore workarounds.
It’s sort of a guilty pleasure to find a way to get by without the right tool for the job. It would be a waste of time under normal circumstances, and not something the client should be billed for, but you can hack with a clear conscience when you’re forced into doing so.
I used to work for a very strict client once – firewalls everywhere, no new software allowed etc. Thankfully they had Excel so I wrote a simple binhex converter in VBA and emailed myself an executable I needed as an innocently looking Excel document with plenty of hexadecimal strings.
Worked like a charm.
https://frippery.org/busybox/
https://busybox.net/
https://landley.net/toybox/
are your friends when all you need is a basic Unix-like environment.
On Windows, don’t overlook PowerShell.
Thanks.
Someone told me that cmd.exe was blocked at his client for security reasons, but PowerShell was enabled. I could see that.
I was into PowerShell when it first came out and wrote several posts here about it. Maybe it’s time to revisit it. Maybe I’ll be forced to revisit it. :)
You might look to see if WSL (or WSL 2) is active on the machine.
https://docs.microsoft.com/en-us/windows/wsl/install-win10
https://docs.microsoft.com/en-us/windows/wsl/compare-versions
I hope WSL isn’t blocked. I really enjoy using it.
There might even be a valid argument for blocking cmd.exe but not powershell: In PS there’s a separate switch for whether or not you can run scripts from a file, which is set to deny by default.
Presumably the concern is for social-engineering users into running malicious scripts that upload confidential documents to someplace public and other things they need the ability to do but are trusted not to; while anything they shouldn’t be able to do at all should already be blocked in a way that PS can’t bypass.
I don’t remember exactly if it is “John Dies at the End” or “This Book is Full of Spiders” by David Wong that contains some scenes in an abandoned shopping mall that makes it look somewhat harder than wilderness survival….
I’ll echo some other people: If Powershell is open, that’ll be a very good first port of call, even if you can only run scripts by pasting them into the ISE.
@Kevin: My abandoned mall metaphor is kinda strained, but I think you’re right about surviving in a mall being harder than it seems. Hopefully you could find some canned goods in the food court. :)
What had in mind was an abundance of things that many people value but aren’t useful. If the mall was still open, maybe the analogy could be plenty of access to junk food but a dearth of fresh vegetables.
I empathise with your guilty pleasure. I enjoy implementing well known algorithms from scratch and it’s hardly ever justified in a professional setting. I envy the opportunity you might have here :)
I too was into PowerShell when it first came out (My enthusiasm was fuelled by some of your posts IIRC) but since WSL came out I haven’t even considered it
At the turn of the century, I was trapped in the IT twisted maze of passages, all alike. Fortunately, Perl was left, probably for their own convenience under the reasonable assumption that it was not spoken among the laity.
Saved my rasher.