161–169 of 169 posts
I usually go with bash + set -euxo pipefail and if it becomes too complicated I switch to Python.
GoLang/Rust are the perfect tool when distributing tools as a single binare. Where in the world does JS fit in?
> Bash is great, but when it comes to writing scripts, people usually choose a more convenient programming language. JavaScript is a perfect choice um… what?
I came across Bash, Powershell, Ruby, Python, Go, Rust, Perl, but JS?
Earlier quoted context omitted.
> First impression is that I wouldn't go near it until it settles down a bit — it was on v1.7 in May and now on version 3 already. Would you feel better if they called version three v1.9 instead?
Given that 3 and 1.9 have a completely different semantic meaning, they might.
Earlier quoted context omitted.
> That's why Perl is my go-to choice for glue scripts. It's almost always installed by default My first thought was related to this as well: Perl is _always_ installed, and based on Python's popularity (compared to Perl, at least), I'd assume that Python also was installed by default? That's an honest question, btw: I use Perl quite a lot, Python not so much (at all). :)
Assuming Python or Perl are installed by default in any server is an invite to a world of pain. At least that's my anecdotal experience.
Earlier quoted context omitted.
I've seen instances of some Unix systems not having Perl installed, but that's very rare. Basically everything directly or indirectly depends on Perl, so you really have to run your scripts on a minimal install of RHEL of FreeBSD with 0 ports in order to get into such a situation.
And for that situation you can always break out http://p3rl.org/App::staticperl . Plus of course if you want to use (pure perl) cpan dependencies I wrote http://p3rl.org/App::FatPacker and http://p3rl.org/Object::Remote to make that easier.
Why do you link to p3rl.org? And, more importantly, why do you link to something that doesn't exist?
Somewhat related, if you are looking to do scripts in Python you should take a look at `sh`: import sh print(sh.ifconfig("eth0")) https://amoffat.github.io/sh/
> Will Windows be supported?
> There are no plans to support Windows.
I personally find Ruby's built-in shell features more ergonomic: `cat package.json | grep name` branch = `git branch --show-current` `dep deploy --branch=#{branch}` if $?.success? [ "sleep 1; echo 1", "sleep 2; echo 2", "sleep 3; echo 3", ].map { |cmd| Thread.new { %x(cmd) } }.each(&:join) name = 'foo bar' `mkdir /tmp/#{name}` if $?.success?
Earlier quoted context omitted.
This isn't correct: if a Googler writes some code from scratch, which is unrelated to their work, on their personal time, and using their personal laptop... then it's definitely not owned by Google. There could be gray areas where code ownership could be disputed, but in general your employer owns only the intellectual property it paid for. Source: I'm a Googler (until next month).
Not true. You need explicit permission (there is a process for obtaining it, and it is very lightweight as I've done it myself). The general idea is that you get permission without much hassle if you develop something that doesn't compete with Google. You need to argue your case otherwise. Source: I'm a Googler that went through the process before. Edit #1 for all Googlers reading this: search "IARC" internally and y…
I went through the IARC process 2 years ago for a startup I was about to found in Tokyo, and obtaining clearance was easy, as you say. It's an extra precaution to avoid future litigation, but not legally required if you keep your personal coding activity clearly and provably separate from your work activity.
Earlier quoted context omitted.
I've seen instances of some Unix systems not having Perl installed, but that's very rare. Basically everything directly or indirectly depends on Perl, so you really have to run your scripts on a minimal install of RHEL of FreeBSD with 0 ports in order to get into such a situation.
Many container base images won't have perl by default (e.g: alpine). For servers it's less common, but enterprise systems never cease to amuse me.