Just because I don't care doesn't mean I don't understand.
511 stories
·
3 followers

Test, [, and [[ (2020)

1 Comment

Did you know that Unix systems have a binary whose name is a single symbol?

Go and look for it. Run ls /bin/? and behold:

$ ls /bin/?
/bin/[

Uh huh. [? The square bracket? That’s a program?!

But wait, it gets more interesting:

$ ls -li /bin/[ /bin/test
834 -rwxr-xr-x  2 root  wheel  35824 Jan 23 08:59 /bin/[
834 -rwxr-xr-x  2 root  wheel  35824 Jan 23 08:59 /bin/test

The two names, [ and test, point to the same binary. But why? What are these?

The test program is what you use in the shell to evaluate an expression. You can use this to compare strings, compare numbers, and to check various conditions on files. If you have written a shell script—any shell script really—you certainly have used either of these variants.

The way this works is simple: the test program takes a bunch of arguments, evaluates the expression represented by them, and returns 0 if the expression is true or 1 if it is false. This then lets you do things like:

if test a = b; then
    echo "The two strings were the same! Oops!"
fi

So why do we have two names for this helper tool? I haven’t been able to find the definitive answer, but my guess is simply: because the above “looks ugly”, and the “obvious” solution to make it look nicer is to introduce [ as a command. With it, you can express the same logic from above as:

if [ a = b ]; then
    echo "The two strings were the same! Oops!"
fi

Yup. Exact same code as above. The only difference here is that the test binary checks its argv[0] to see if it’s invoked as test or as [. If the invocation happens to use the latter, then the program ensures that the last argument is the matching ] to keep things balanced.

With that, you can deduce that you don’t even need the conditional statement to use either of these commands and see what’s going on:

$ test a = a; echo $?
0
$ test a = b; echo $?
1
$ [ a = a ]; echo $?
0
$ [ a = b ]; echo $?
1

That’s right. The if statement we used in the previous examples just takes a command as its argument and runs it to get its exit code. (And with this, you can “guess” that true and false are… yup, yup… also helper binaries.)

To make things more confusing, though, pay attention to the following:

$ /bin/test a b
test: a: unexpected operator
$ test a b
dash: 2: test: a: unexpected operator

Why did we get different outputs there? Well… as it so happens, test and [ appear a lot in shell scripts. Invoking them as separate binaries would be very inefficient, so the vast majority of the shells implement these commands as built-ins too. You may get different behavior depending on whether you run the external binary or the builtin, which means you easily get different behavior across different shells. (And that’s true for many other things like the innocent-looking echo.)


So what about [[? This is a Bash extension and replaces the use of [. The key difference, however, is that [[ is guaranteed to be a builtin and therefore it can change, and it does change, the fundamental rules of the language within the expression it evaluates. To illustrate this, let’s look at an example with globs:

$ touch long-name
$ [ long* = long-name ] && echo match
match
$ [[ long* = long-name ]] && echo match

The first command shown here is an invocation of the [ tool, which may or may not be a builtin. No matter what, all arguments are subject to the regular shell expansion rules, so long* is matched against the directory contents, is then expanded to long-name, and thus the test succeeds. But, in contrast, [[ produces a different result because it treats the long* as a literal string, so all this is doing is comparing long* against long-name verbatim, and therefore failing.

What should you use, then? If you are writing a portable shell script (please do), then stick to [. You can also use test, but I don’t think that’s too common. But if you know your script is going to be Bash-specific anyway, you are probably better served by using [[ unconditionally and consistently, as it provides a lot of nice features (like regular expression matches via =~).


And now for the final lolz. I’ve said above that these are the commands you use to evaluate expressions… but the shell also has expressions of its own via the !, &&, and || operators—all of which work on command exit statuses. That is:

$ grep ^hello$ /usr/share/dict/words && grep ^bye$ /usr/share/dict/words
hello
bye
$ echo $?
0
$ grep ^tyop$ /usr/share/dict/words && grep ^bye$ /usr/share/dict/words
$ echo $?
1

Which means… that you can combine test expressions and shell expressions in one invocation:

if [ a = b ] || grep -q ^hello$ /usr/share/dict/words; then
  echo "test failed and grep succeeded"
fi

You pick whether to be amused or horrified. I don’t know how exactly my coworker reacted when I hinted at this during a recent code review I did for them.

Adblock test (Why?)

Read the whole story
jgbishop
5 days ago
reply
My primary takeaway from years of Bash scripting is: choose a better language to do stuff in!
Durham, NC
Share this story
Delete

“I built a trading bot that buys stocks that are being bought...

1 Comment
“I built a trading bot that buys stocks that are being bought by politicians. It is up 20% since it launched in May 2022. The market has been flat during the same time period.” More here.
Read the whole story
jgbishop
17 days ago
reply
Very interesting.
Durham, NC
Share this story
Delete

I Skipped to the Ending

1 Comment

When I was 8 years old I started making websites with my friend. His grandmother had purchased him a domain name and web hosting. It was 2003 and the world was whispering of Web 2.0. Books I checked out of the library talked about DHTML (dynamic HTML, basically what any web app is today). There was no mobile app market, native application development had a high barrier to entry, and the most exciting things happening with computers were websites like eBay and Google.

Together my friend and I would make silly web pages. Basic things like choose-your-own-adventures were fun and easy to make. All you needed were some links to the next pages and you’ve made a game! We of course had the most offensive color schemes imaginable. We had 24-bit JPEG backgrounds of landscapes and tropical coasts. They were the most beautiful images I could find online, so why shouldn’t they be the backing for my red 12pt Times New Roman text?

At some point I saw a picture in the Philadelphia Inquirer of a slide in an office building and an all-you-can-eat free candy dispenser. Google was becoming the first “web scale” company in real time. And they were rewarding the employees handsomely for reshaping the world. Every year they would release a reality-altering product. Google Earth blew my mind. I could spend hours scanning around in the American deserts finding interesting canyons and mountains. In high school I had my own personal site that functioned mostly as a blog. It was a major point of pride that I wrote the HTML and CSS by hand - I even made the graphics myself in Paint. At least one post showcased the highlights of my discoveries in the satellite imagery of Google Earth.

My family would all talk about how some day I’d work for Google. I believed them and considered Google to be the apex of a programmer’s career. They paid the most, got the most done, and their employees held the most respect.

So when I graduated with my Bachelor’s in CS and got a cold email from a recruiter I was ecstatic! Soon they flew me off to interview on-site in Seattle. I can only guess why, but I did not make the cut. My fall-back was to go work in startups in Silicon Valley. I already had a few good projects, co-ops, and part time jobs under my belt. My experience earned me a few competing job offers. I picked the better of the two and moved across the country.

What shocked me was how healthy the startup job was. There was no grinding, a good work-life balance, and a set of 20 kind and knowledgeable co-workers. Everyone was there because they wanted to be there. We all wanted to build something, together. I sat next to the founding engineer for a year and learned more per day than I ever had before or have since. The guy was notoriously blunt. His bluntness honed my edge.

During the pandemic I switched jobs to work at a rapidly growing startup in the emerging AI/LLM space. I had dropped into a runaway success. After only 8 months the founders had achieved thousands of signups per day, millions in ARR, and I was here to rewrite everything from scratch. We shipped the rewrite after a couple of months and used the fire hose of new users to iterate on on-boarding and product functionality. Being able to go from ticket to PR, LGTM, release, and get metrics in a hour is an amazing way to learn. Consistent, fast feedback is one of the key aspects to becoming an expert.

But for all of the team’s virtues we also had our failings. Soon it became clear that we didn’t have a strong direction in the face of a rapidly changing landscape. A GPT-3 app could not stand still, certainly not one with VC funding. I started to grow uncertain of the value of my time spent there. Then I got another cold email from Google. They wanted me to interview again. I gave it a shot and got an offer for an L4 SWE position. After almost 20 years I had gotten into the magic place with slides and free candy.

Figuring I might as well take the opportunity to try some different work, I joined a team working on phone firmware. After a couple of weeks the tech lead quit. My manager would often not reply to my emails. They told me I didn’t need to do any work for the first couple of months. This is the last thing I wanted to hear. When I did get work assigned I was immediately thrown into the jaws of bureaucracy. A project to help us track errors in production would take months. Most of that time got allocated to getting Privacy Council approval because we would be logging strings. My team all lived nearby but rarely came in to the office. Virtual meetings were held with cameras off. Co-workers started quitting left and right.

I came to realize that I had joined the wrong version of the team. There was one team working on this product specifically for first-party phones, and another for the platform at large. But because Google refused to offer support to 3rd party OEMs, even at a price, none would sign on. Hiring got frozen so I couldn’t switch to the “real” team.

And so my new skip manager told me he would have the team shut down and I switched to an adjacent team managing a certificate authority. This would be web-based work. After my failed entry into Rust firmware development I was glad to go back to my roots.

As it turned out, the web side of this project was maintained by another department. I was on loan to them. I got assigned a “dotted-line manager”. When I first met him he gave me a speech about how he didn’t want to hear anything about my working on 20% projects - “they always end up being more than 20%”. He didn’t want me to get pulled into work by my direct manager. He felt he owned me.

After finishing my first project I made the mistake of picking up new work because I had nothing else to do. Mr. Dotted-Line and his team had put together a list of tasks for the next few quarters without me. I picked the first unassigned item in the document and sent out a design document for what would end up being 200-300 lines of code. Big mistake - I was going rogue. Dotted-Line contacted my skip manager demanding I be reined in. My skip and direct managers had my back, but I still felt awful. Was I not supposed to be learning? Building?

Not that my other managers were amazing to be around. My direct manager would fantasize about monetizing male loneliness through futuristic sex robots. Later, when my skip manager was staging a coup to steal Dotted-Line’s project he pulled the other guy into a call. During the call he opened up a group chat with my team, writing:

Skip: He is fighting it

Skip: But he also looks like his dog got shot

Skip: He is now pitching for us to work better together

Skip: Feels like a breakup lol

…no one responded.

“Those guys over there are so toxic” was a favorite phrase for him.

As I realized this project was no better than the last one I made my complaints clear to my direct manager. I told him my issues were with the company itself and had no optimism that working on yet another project would fix things.

He told me (paraphrasing) “Well, you know it’s really a lot of paper-work to fire you. You could just get away with doing nothing for 12 months.” Again, not what I wanted to hear. Why tell me this? Presumably for him this was a way to pad his head-count. One of the primary metrics for leadership success at Google is how many people you have under you. It doesn’t matter if one, two, or more aren’t working - as long as you are meeting your self-defined OKRs you’ll look good.

It’s the same motivator for why my dotted-line manager wanted to steal me. Hiring got frozen - the only way to get that sweet sweet head-count is to take it from someone else.

So after 15 months I was out of there. I learned that I don’t care about the money Google pays. I don’t care about the high scale of influence your work can have. I skipped from series A startup to mature IPO’d company and cheated myself out of the experiences you get in-between. I want to earn the scale through hard work. For me FAANG was not a place to learn, it was a way to get paid. But I didn’t come to Silicon Valley to get paid.


P.S: I want to be clear that all of the ICs I worked with were great. If any of them read this they should know I appreciated their time spent working with me.

Adblock test (Why?)

Read the whole story
jgbishop
18 days ago
reply
I'm glad I don't work for Google.
Durham, NC
Share this story
Delete

Lemmings

1 Comment

I was going to call this post Cargo Culting but I think the term is inaccurate as much as it is antiquated. In fact, I'd be happy if we cut the wartime rhetoric out of tech entirely, as if getting a 64k bill from a badly built Lambda function is as bad as getting trench foot in Alsace-Lorraine or waiting for a care-package that will never come, but that's a topic for another time.

Instead, I want to talk about the apocryphal Lemming-like phenomenon of people in tech blindly following trends and how it is far from specific to software engineering. I promise, this one is gonna be short.

In 2022, one or two prominent startups decided it was time to drop some ballast (as it were) and a round of layoffs ensued. This gave legitimacy to every other VC-backed startup firm to kick off their own round of layoffs because that's what everyone else is doing. The first few companies to do it attracted most of the heat, carving out the path for others to follow.

In late 2022/early 2023 it is decided that COVID is no longer a thing and return to office (RTO) comes out in full force. It only required one prominent tech company to enforce this policy and say that the loss of remote staff is acceptable for everybody else to get on board.

In mid 2023 it becomes clear a company can enjoy the benefit of shedding ballast and getting people in the office by enforcing an even stricter RTO policy, without triggering any legal redundancy proceedings. This is not a conspiracy, by the way - in the UK it is well-known as fire-and-rehire where the employer simply changes the contract by terminating your existing one and offering you a less beneficial contract to continue in the job.

How exactly has all of this happened? It is simply because a small handful of businesses set the stage for every other business to follow, and then this grows from a trend into status quo.

If you ask anyone, they will likely say… everybody else is doing it so why shouldn't we?

Anyone who has spent their time working as engineers in tech startups will be familiar with this idea, particularly as it pertains to actual tech.

Why are we using kubernetes? It's because everybody else is.

Why are we using the cloud? It's because everybody else is.

Why are we using Kafka? It's because everybody else is.

Why are we using React? It's because everybody else is.

Why are we using XYZ? It's because everybody else is.

I'll leave it at that.

Adblock test (Why?)

Read the whole story
jgbishop
18 days ago
reply
Lots of truth here.
Durham, NC
Share this story
Delete

Study: People Who Are Obsessed With Celebrities May Be Less Intelligent

1 Comment

A Hungarian study has found “a direct association between celebrity worship and poorer performance on cognitive tests,” with data showing high scores on the Celebrity Attitude Scale correlating with lower performance on the two cognitive ability tests. What do you think?

Read more...

Read the whole story
jgbishop
19 days ago
reply
Well, duh!
Durham, NC
Share this story
Delete

Frazz by Jef Mallett for Sun, 05 Nov 2023

1 Comment

Frazz by Jef Mallett on Sun, 05 Nov 2023

Source - Patreon

Read the whole story
jgbishop
22 days ago
reply
Nice.
Durham, NC
Share this story
Delete
Next Page of Stories