mohsen

APH: Avoidable Person-Hours

2022-08-12T00:00:00+00:00

A couple of years ago, I made up a new unit to measure the efficiency and necessity of meetings: APH (Avoided Person-Hours) Let me explain it. “Avoidable Work” is work that is not necessary, wrong, and wasted and it should be avoided.

Sometimes parties and stakeholders are not on the same page.
Sometimes customers’ request is misunderstood.
Sometimes other forms of communication are slow and inefficent.

And many more issues that all lead to wasted hours of avoidable work.

How many unnecessary person-hours does holding a meeting can help you to avoid in the future?

I remember once a customer asked us to add a feature. It sounded like a reasonable request and would take 2-3 months of work. But they hadn’t told us why they needed that feature. We met with them to understand the bigger picture and design the system to accommodate the probable future requests. We realized that what they wanted to do was already possible with the existing features. So with a 1-hour meeting, we avoided 2-3 months of work. That was a valuable meeting and a precious lesson.

For each meeting, ask yourself:

How many unnessary person-hours can you avoid by that meeting?
Could that avoidable work have been avoided in other ways? Chat? Email? Shared doc?
Could you avoid even more unnecessary person-hours?
How can you avoid similar type of avoidable work in the future without having to have another meeting like this?

Measuring meetings’ APH not only allows you to decide if a meeting is required or not, it also helps you to choose the form, participants, and agenda to maximize yout meeting’s APH.

make up your knapsack

2022-08-05T00:00:00+00:00

What I know about myself is that my decision-making capacity at any given moment is limited. I’ve started seeing my capacity as a knapsack.

Then I put anything I need to decide in one of the three imaginary buckets: Small, Medium, and Large. The definition of each size is very subjective. For me, for example:

Small: Tea or coffee? Which cloth to wear today?
Medium: Which cloth to buy? Which restaurant to go to?
Large: Accepting a job offer, buying a house or a car

Over the first few months, I observed how I dealt with decisions and got a grasp of my decision-making knapsack capacity. Although my knapsack capacity changes under different circumstances (pressure, stress, …) but not significantly. I know, for example, at any given moment, I can deal with:

2 small + 1 medium
Or two medium
Or one large

But not more. If the knapsack is full, I take out (decide or put off) some stuff first and only then I put in the new stuff, as long as it does not exceed the knapsack’s capacity.

Keep it simple though to avoid ending up with a hard Knapsack Problem :)

SwiftUI: Double-Edged Sword

2020-06-21T00:00:00+00:00

One reason that I favor SwiftUI over UIKit is that SwiftUI is architecture-less. That is, SwiftUI doesn’t assume what architecture you are going to use. In contrast to UIKit that assumes you build your app using the MVC pattern. Whatever architecture you come up with, eventually, MVC pattern creeps in somewhere somehow. Regardless of how consistent and flawless your architecture is, you are doomed to interact with UIKit, and these surfaces of interaction are where MVC pattern leaks into your code. On the other hand, in SwiftUI you are completely free to choose the architecture you are comfortable with and don’t need to be worried about the Apple preference. This freedom allows you to build a more coherent and uniform architecture. Although, in lack of a scaffold, as we used to have in UIKit, this time instead of ending up with Massive View Controller, we may slide into the Big ball of mud. More freedom comes at the cost of more responsibility.

salary: confidential

2020-04-26T00:00:00+00:00

Recently, I disclosed my salary to someone and I couldn’t help myself asking if it was the right decision. Most people, including me, are usually unwilling to disclose their salary. Who does benefit from this secrecy? employer. It’s scary how the fear of being judged gets us to act against our self-interest. We fall into this trap because we translate our salary to our value and omit to separate our identifiy from our profession.

I can think of 4 reasons for which people don’t want to talk about their salary:

You disclose your salary and you find out that your mate, equally or less qualified, making more. You feel you have failed in selling yourself and your employee has exploited this opportunity and pay you less than you deserve. You feel you are a fool.
You disclose your salary and people judge your ability and skills based on your salary, not the other way around.
You are humble and are afraid that you may hurt your mate’s feelings when they find out you’re making more money.
You think you are making more money than you deserve and are afraid that you wouldn’t be able to defend it if someone questions you.

Of course, none of these reasons justifies this decision. But it’s what it is.

I still have a few open questions though:

How can we rephrase this topic in game theory terminology
How does it align with one my principle that says “if you HAVE TO hide something, there is something WRONG.”
What is the share of the lack of a fair evaluation system in getting us to this paper on the crack solution (not to talk about salary to avoid conflict)?

awkward phase

2020-01-19T00:00:00+00:00

Are you switching from your old architecture to a new elegant sophisticated promising one?
Are you moving from an inconsistent non-scalable UI to a design system based UI?
Are you swapping an old deprecated module with a brand new fresh one?
Are you migrating from an old fashion document-less backend to a new shining cutting-edge one?

So you’re in an awkward phase. Aren’t you?

“Awkward phase” is the name I use to refer to the transition phase from a state to a better one. It’s awkward because you’re not in a stable state. You’re neither in the source state nor in the destination state. You neither benefit from being in the state you’re familiar with nor benefit from the advantages that the better state provides. You still suffer from the flaws of the first state while you need to concentrate on how you can get to the better state without messing up. Your cognitive load (Cognitive load - Wikipedia) is two times more than before.

We all were there at least a couple of times. We get excited for the bright stress-free future that the new state (new architecture, UI, module, backend) promises and are thrilled that we will be able to get rid of the old frustrating dead-end hard-to-maintain state (old architecture, UI, module, backend).

But the path gets us there is dark and dangerous. We should not stop. We’ve got to run. We can not pause, deprioritize or abandon it once we start it. We can not just stand somewhere between. We should remember the transition phase is awkward. We have to maintain two documentation, two pieces of code, two sources of bugs, two solutions, two explanations, two sets of edge cases, … cognitive load x 2.

Before entering into an awkward phase, make a plan, know exactly how you want to go to the new state, what risks you may face, what you need to have and what you need to do, then take your breath and run. In case you change your mind, don’t stop, don’t pause, don’t slow down. Come back to the previous state. Clean your footprint. Roll back to the old state. Don’t make people confused about what state you’re in. Being in a bad state sometime is better than being in the awkward phase. Although minimizing cognitive load is always better.

apple doesn’t slow iPhone down, we do

2019-08-23T00:00:00+00:00

There has always been a conspiracy that Apple deliberatly slows iPhone devies down to make people to buy new one. Is it true?

Part I: I lost my brand new iPhone ☹️

I lost my iPhone XS three weeks ago. I don’t want to buy a new one again any time soon. So I fished my old iPhone 5s out of my drawer. Setting it up, I noticed it is slow. To be accurate, it was too slow. Slower than when I was using it as my main device/phone. It’s unbearable. Why is it so? What happened in the last 2-3 months? Has Apple done some magic to persuade me to buy a new phone?

The answer is … No.

Apple hasn’t done anything to deliberately throttle my phone.

Part II: a craving to consume more

Probably you have blamed Chrome or Slack for using too much RAM too. But this is a wide and deep problem. It’s not easy to find a piece of software that is built with as much thought and effort put into making it memory efficent as developer used to do. Look at this supposedly tiny winy software that the only thig does is mirroring my screen on a conference room display. After keeping it open for 2 or 3 hours, it gets to the points:

Right now, I don’t have any important software open on my laptop and 11GB of RAM is already full. 6 years ago, my laptop had 2GB of RAM and it was enough!

What’s going on under the hood? Why do softwares eat too much nowadays?

Part III: a frame drops, an instrument rises

When was the last time you monitor the performance of the app you’ve been developing? Is it part of your everyday routine? Most of the time we use them when something is terribly wrong: app crashes, UI freezes, scrolling looks erratic, customer complains. Rarely benchmarking is integrated into our development process. It’s more like an occasional thing.

Barely you leave an interview haven’t answered some questions about big O notation. We can compare common data structures top off our mind. We know popular algorithms by heart. We can explain which ones outperform which ones. We all admit writing efficient software is precious. Yet everything in the market encourages use to leave old devices behind. The hardware industry goes forward fast and we’re trying to catch up. But it comes at a price: Old devices get ignored, their owners get forgotten. But soon or later, we realize that the number of ignored users are growing and maybe we should include them again. So this is why Lite version of apps is becoming a thing (Facebook Lite, Spotify Lite, Twitter Lite, Skype Lite, … and just recently Google Go Lite). Although many of them are nothing more than the existing product minus some features.

Part IV: Good Old Days

Last year I read Game engine black book: Wolfenstein 3D. It’s fascinating. To me, it is a treasure chest. As folklore and Code Secret are. Sometimes what you find on reddit or in an interview impresses you. They sound like fairy tales. When software development is more about crafting than wrestling with a bunch of technologies, tools, frameworks and sitting top of shaky stacks of unknown or hard-to-be-known layers. When people pay attention to each line of code they write and every byte of memory they use.

I felt over the course of time we, developers, are getting negligent and careless. We believe memory is a customer’s problem, not ours.

Part V: I won’t suck it up (at least for now)

I’ve decided to develop my next iOS side project for an old iPhone. I even tried to find iPhone 4, but no success yet. I’m curious to see what obstacles I will encounter and how I can find my way around them.

daily standup: where scrum flys or dies

2019-06-23T00:00:00+00:00

It was roughly nine years ago when I attended my first official Scrum Daily Standup. I among my four teammates went to our manager office at 10 in the morning. After 10min, when we were done, I felt it was useless. Since then (almost) in every company I worked at, we had some kind of daily standup. Except for a few times, I never enjoyed being in a standup. Usually, standup is the first thing a company/team starts with when they decide to adapt to Scrum or any variation of Agile methodology. Honestly, from company perspective, it is the cheapest and less risky part of Scrum. Just 5 minute per day. Any implementation of Scrum Daily Standup I’ve experienced so far was kind of a failure, most of the time partially and sometimes completely. I, as an observer of all these failures, asked myself every time, after every standup, what needs to be changed? Until 5 months ago, when I learned how a standup suppose to be.

2 Years Ago: When I read that book

Until 2 years ago, everything I knew about Scrum and Agile methodology I had learned from non-original resources. 2 years ago, accidentally, I found this book in a small abandon library in my previous workplace:

It explains Scrum, in the purest form. If you want to learn or re-learn Scrum, it’s a must-read. What is my most important takeaway from this book? Scrum is a mindset which you build and the rest (backlog, standup, planning, retrospective, … ) comes after that. They are all inevitable results of this mindset. If you build this mindset, organically, gradually, over course of time, in search of solutions for natural problems your team struggles with, through process of customization, you invite them again and one day you realize you have been doing standup, backlog/sprint planning and retrospective, may under different names. You don’t know since when. But you invented them again and customized them according to your needs and have been using them to become and stay agile. I believe this the biggest mistake people make when they try to adapt to Scrum. They start from tools to get to mindset. But it’s the other way around:

5 months ago: Such a pleasure

It’s was my first standup in the new company. I liked it. I enjoyed. After that, I felt we are more than a tech/dev team. I felt we are a squad, like how that book describes a scrum team. Every single standup was useful. It helped me to become agile, more flexible, more team-player. But why? What was the difference between the standups we held here with all other standups I’ve been in in the past?

Good Standup, Bad Standup

OK. I don’t have a formula or theory (yet!). The only thing I have is a bunch of signs and flags which I have built my litmus test based on.

A bad standup is like a reporting meeting, where you report to your direct manager or your customer. You talk more about the past and what you have done and less about the future and what you’re going to do. You attend the standup because your manager has asked you. You do it because your customer/manager wants to know more, every day, about the progress. You get bored. If you hadn’t attended it, you wouldn’t have missed anything important.

A good standup is like being in a war room. It all about re-evaluating the situation, re-organizing the team accordingly, and proceed. The ultimate goal is filling each other’s gaps and build a complete team out of incomplete individuals. During a good standup, you hear this kind of sentences a lot:

I can pair up with you.
I can pick up this task.
Can you help me? I know you encountered a similar issue in the past.
I know how we can solve it. We can talk about it after the standup.

In a good standup, people talk more about what they are going to do and less about what they have done. You attend it for yourself, for your team, because you’ve experienced how it increases your agility. Even when your manager/customer doesn’t attend standup, you still find it useful and necessary.

Let’s model a standup with a graph. Each node in this graph is a person and we draw a line from A to B if at some point in standup A talks directly to B. This is how a bad standup looks like:

And this is how a good one is:

Fly or Die

Standup is important. If it fails, the whole implementation of Scrum will fail. You can look at it as an indicator. Every day you repeat it. Every day you have the chance to see if your standup is quality or not. If your team has adapted to the agile mindset or not. If you are on the right track or not. This 5min meeting reflects the sprint of your team and how far you are from being an agile, flexible, coherent team.

a dead simple solution to lift up errors in ios

2019-06-09T00:00:00+00:00

In this post, I want to show you how you can utilize the responder chain to bubble up an error message through your app UI structure till it gets to the node which can handle it. It is especially useful if you are a fan of Container View Controller. Responder Chain is a linked list built and maintained by iOS that represents the prioritized list of object that potentially can respond to events that occur in UI. If you like to learn more about Responder Chain pattern in general here or more specific in iOS here and here.

Suppose that you have a nested structure of views and view controllers that presents the UI of your app. If something goes wrong in any of this view controllers or views and you don’t want to handle the error there and you prefer you pass it up to its ancestors, you might use delegate pattern or closure or other solution. But you usually end up adding some kind of one-direction wire between views and view controllers which have parent-child relation. Fortunately, we already have this one-direction wire between parent and child for free and we just need to use it.

Here is what you can do:

extension UIResponder {
    @objc
    func showError(message: String) {
        self.next?.showError(message: message)
    }
}

Here we add a method to UIResponder that consequently, this method will be available on any UIView, UIViewController, UIWindow or UIApplication. What it does is really simple, it passes the error to the ancestor of the current UIResponder object. If we override this method in a subclass of UIResponder, we will be able to catch the error and handle it however we like.

You might use a more sophisticated parameter for showError. For example, you can pass an Error instance, so that an UIResponder can handle just some type of error and passes those that don’t handle to its ancestor.

Here is an example:

class WhiteViewController: UIViewController {
    var errorLabel: UILabel!
    
    override func viewDidLoad() {
        super.viewDidLoad()
        
        view.backgroundColor = .white
        
        // Add a child view controller
        let childVC = RedViewController()
        childVC.view.frame = vc.view.bounds.insetBy(dx: 50, dy: 50)
        addChild(childVC)
        view.addSubview(childVC.view)
        childVC.didMove(toParent: self)
        
        // Add a label for showing error messages
        errorLabel = UILabel(frame: .init(x: 0, y: 0, width: view.frame.width, height: 40))
        view.addSubview(errorLabel)
    }
    
    override func showError(message: String, fatal: Bool) {
        // Show the error message and clear it after 1sec
        errorLabel.text = message
        DispatchQueue.main.asyncAfter(deadline: .now() + 1) { [weak self] in
            self?.errorLabel.text = ""
        }
    }
}

class RedViewController: UIViewController {
    var errorLabel: UILabel!
    
    override func viewDidLoad() {
        super.viewDidLoad()
        
        view.backgroundColor = .red
        
        // Add a child view controller
        let childVC = GreenTableViewController()
        childVC.view.frame = view.bounds.insetBy(dx: 50, dy: 50)
        addChild(childVC)
        view.addSubview(childVC.view)
        childVC.didMove(toParent: self)
        
        // Add a label for showing error messages
        errorLabel = UILabel(frame: .init(x: 0, y: 0, width: view.frame.width, height: 40))
        view.addSubview(errorLabel)
    }
    
    override func showError(message: String, fatal: Bool) {
        if fatal {
            // Show the error message and clear it after 1Sec
            errorLabel.text = message
            DispatchQueue.main.asyncAfter(deadline: .now() + 1) {  [weak self] in
                self?.errorLabel.text = ""
            }
        } else {
            // Pass the error to the ancestor
            next?.showError(message: message, fatal: fatal)
        }
    }
}

class SimpleCellView: UITableViewCell {
    var fatal: Bool!
    
    override func setSelected(_ selected: Bool, animated: Bool) {
        super.setSelected(selected, animated: animated)
        if selected {
            showError(message: "Something went wrong!", fatal: fatal)
        }
    }
}

class GreenTableViewController: UITableViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        
        view.backgroundColor = .green
        
        self.tableView.register(SimpleCellView.self, forCellReuseIdentifier: "SimpleCellView")
    }
    
    override func numberOfSections(in tableView: UITableView) -> Int {
        return 1
    }
    
    override func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
        return 10
    }
    
    override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
        let cell = tableView.dequeueReusableCell(withIdentifier: "SimpleCellView") as? SimpleCellView
        cell?.textLabel?.text = "Cell #\(indexPath.row)"
        cell?.fatal = indexPath.row % 2 == 0
        return cell!
    }
}

extension UIResponder {
    @objc
    func showError(message: String, fatal: Bool) {
        self.next?.showError(message: message, fatal: fatal)
    }
}

This is the responder chain of this example:

Responder Chain:
 
UIApplication (next: nil)
 |
 |__ UIWindow (next: UIApplication)
      |
      |__ WhiteViewController (next: UIWindow)
            |
            |__ RedViewController (next: WhiteViewController)
                 |
                 |__ GreenTableViewController (next: RedViewController)
                      |
                      |__ SimpleCellView #1  (next: GreenTableViewController)
                          SimpleCellView #2  (next: GreenTableViewController)
                          SimpleCellView #3  (next: GreenTableViewController)
                          SimpleCellView #4  (next: GreenTableViewController)
                          SimpleCellView #5  (next: GreenTableViewController)
                          SimpleCellView #6  (next: GreenTableViewController)
                          SimpleCellView #7  (next: GreenTableViewController)
                          SimpleCellView #8  (next: GreenTableViewController)
                          SimpleCellView #9  (next: GreenTableViewController)
                          SimpleCellView #10 (next: GreenTableViewController)

In SimpleCellView when user selects a cell, showError is called:

override func setSelected(_ selected: Bool, animated: Bool) {
    super.setSelected(selected, animated: animated)
    if selected {
        showError(message: "Something went wrong!", fatal: fatal)
    }
}

Because we haven’t overriden showError in SimpleCellView, the default implementation is called:

func showError(message: String, fatal: Bool) {
    self.next?.showError(message: message, fatal: fatal)
}

The next item in the chain is GreenTableViewController which doesn’t have an overridden version of showError, so the default implementation is called again and the next item in the responder chain is RedViewController. It has an implementation of showError but catches and handles the error which is fatal, otherwise passes it to its ancestor which in this case is WhiteViewController:

override func showError(message: String, fatal: Bool) {
    if fatal {
        // Show the error message and clear it after 1Sec
        errorLabel.text = message
        DispatchQueue.main.asyncAfter(deadline: .now() + 1) {  [weak self] in
            self?.errorLabel.text = ""
        }
    } else {
        // Pass the error to the ancestor
        next?.showError(message: message, fatal: fatal)
    }
}

Those errors which are not fatal get to WhiteViewController and it handles them all equally:

 override func showError(message: String, fatal: Bool) {
    // Show the error message and clear it after 1sec
    errorLabel.text = message
    DispatchQueue.main.asyncAfter(deadline: .now() + 1) { [weak self] in
        self?.errorLabel.text = ""
    }
}

__NSSingleObjectArrayI: an existential crisis

2019-06-02T00:00:00+00:00

When you create an new instance of NSArray, inside arrayWithObjects:count: (which can be called directly and is called indirectly by other constructors and also is that method is used internally to create an array from a literal array) depending on how many items it has, under the hood NSArray may create either an instance of __NSArrayI(Runtime Header file) or an instance of __NSSingleObjectArrayI (Runtime Header file). Actually, if the array contains one item, NSArray create an instance of __NSSingleObjectArrayI, otherwise __NSArrayI gets used.

NSArray *arr1 = @[@(1)]; // arr1 is __NSSingleObjectArrayI
NSArray *arr2 = @[@(1), @(2)]; // arr2 is __NSArrayI

By looking at __NSSingleObjectArrayI.h you will notice that this class has a protected variable, called _object, that I guess it is where the single item of the array is stored.

@interface __NSSingleObjectArrayI : NSArray {
    id  _object;
}

As soon as you learn that single object arrays are treated differently, an important question arises: What is the necessity of having a separate type for array that has just one object? My first guess was Performance, either in terms of speed or memory usage, or maybe both. I tested my hypothesizes and I like to share the results with you. If you like to learn more about benchmarking in Objective-C/Swift, read “Benchmarking” by Mattt. To test my hypothesizes I utilizeed what I had learned from this article.

Hypothesis1: It is faster

I measured how much it takes to create an instance of NSArray. The varibale of this experiment was the number of items the array contains. Also, I was curious if specifing the type of array’s items make any difference. So I repeated experiments once again but this type specified the type of arrays’ items:

Case#	Array	Time
Case1	`NSArray *arr = @[@(1)];`	2.62712e-05 s
Case2	`NSArray<NSNumber > arr = @[@(1)];`	2.59094e-06 s
Case3	`NSArray *arr = @[@(1),@(2)];`	1.91713e-06 s
Case4	`NSArray<NSNumber > arr = @[@(1),@(2)];`	2.41189e-06 s
Case5	`NSArray *arr = @[@(1),@(2),@(3),@(4),@(5),@(6),@(7),@(8)];`	2.89804e-06 s
Case6	`NSArray<NSNumber > arr = @[@(1),@(2),@(3),@(4),@(5),@(6),@(7),@(8)];`	3.00701e-06 s

In general, create an instance of __NSSingleObjectArrayI is slower than __NSArrayI, and specifying the type of array’s items makes the creation faster. Then I measured the amount of time it takes to access the first item of an array. The varible was the type of array, but the access method was the same:

Case#	Array	Time
Case1	`NSArray *arr = @[@(1)];`	4.65124 s
Case2	`NSArray<NSNumber > arr = @[@(1)];`	4.61453 s
Case3	`NSArray *arr = @[@(1),@(2)];`	4.11629 s
Case4	`NSArray<NSNumber > arr = @[@(1),@(2)];`	4.04419 s
Case5	`NSArray *arr = @[@(1),@(2),@(3),@(4),@(5),@(6),@(7),@(8)];`	4.05391 s
Case6	`NSArray<NSNumber > arr = @[@(1),@(2),@(3),@(4),@(5),@(6),@(7),@(8)];`	4.09293 s

As you can see, accessing the first item of an array of __NSSingleObjectArrayI type is slower than __NSArrayI, and specifying the type of array’s items enables us to access the first item faster.

Hypothesis2: It reduces memory usage

I ran another experiment. This time in each test case, I created 1000 instance of array with N items and used Instruments to measure how much memory was used to store these instances. This time, the variable of the experiment was N: Here is the result:

Case#	Array	Memory
Case1	`@[@(1)]`	156,25 Kb
Case2	`@[@(1),@(2)]`	312,50 Kb
Case3	`@[@(1),@(2),@(3)]`	468,75 Kb
Case4	`@[@(1),@(2),@(3),@(4)]`	468,75 Kb
Case5	`@[@(1),@(2),@(3),@(4),@(5)]`	625,00 Kb
Case6	`@[@(1),@(2),@(3),@(4),@(5),@(6)]`	781,25 Kb

Even when we compare memory usage, there is no significant difference between these two (size of @[@(1),@(2)] x 2 = size of @[@(1)], that makes sense).

Conclusion

I don’t still understand the reason behind having a separate type for immutable arrays that have just one item, though I know now that neither is faster nor used less memory. On the other hand, I couldn’t find a use case where someone needs to create thousands instance of single object array so might this subtle difference become important for the developer. Maybe this is why no one has ever complained about that. The only case where I can image this difference might be important is where a JSON gets decoded. Because if a JSON array has just one item, the decoded type will be __NSSingleObjectArrayI. So if you are working on a program that its performance is critical and somewhere in this program you have to decode a huge JSON which has many single item arrays, you should be more careful.

bash: going down the rabbit hole

2019-05-26T00:00:00+00:00

Question

Last week when I was looking at a bash script file, I saw this line:

[[ $FOLDER_NAME == "ios" ]] && lib="lib-osx-amd64" || lib="lib-linux32"

I’m not a bash expert, so this line caught my attention. At first, I thought what A && B || C does is similar to what A ? B : C in many programming languages does. It takes a few hours of debugging, reading and thinking to realize this hypothesis was wrong! Actually, if you’re using A && B || C in bash how you use A ? B : C in other programming languages without knowing what is happening under the hood, and it works for you, you are just lucky!

Contradiction

After seeing that line, I started searching on the web to learn what that line means. The first thing I noticed after reading some articles and answers was that many people don’t know that line gets evaluated by bash and they have given up to understand it. The vaguest aspect of evaluation was the precedence of operators that looks is different than when they are being used within a condition expression. Actually, you can not find any piece of information about it. The more you search, the less you find. The only thing you can find is the table of Operator Precedence ( for instance this one ) that doesn’t say anything about when these operators are used in this kind of usages. But at least you know that if && and || getting used within a condition, how they get evaluated. && has a higher precedence than ||. So:

[[ A || B && C ]]

First B && C is evaluated ( lets call this expression q ). Then A || q is evaluated.

[[ A && B || C && D ]]

First this expression q := (A && B) ( note: q := X means from now on, we refer to X as q )
Then this one p := (C && D)
And finally, q || p

But what about when these two operators are used outside of a conditional expression? Are && and || we are using in a conditional expression and the ones I saw in the bash file, in essence, the same thing. Are we tricking Bash and uses AND and OR logical operators to simulate ?:?

When you can not find your answer by searching on the web, it means you need to get your hand dirty! Let’s take a look into the bash source code.

How to set up our lab

Obviously, there are thousands of thousands of way to set up your lab, but here I’m showing you how I did it for this example:

Download Visual Studio Code
Download C/C++ Extension for Visual Studio Code
Clone bash source code ( it’s a mirror of the source code )
Build it. It’s really simple. a. go to the source code dir b. run ./configure c. run make and once it is done, you find a bash executable file in the directory If you’re interested in learning more about the process, look at this file.
Run it Be Careful: if you run bash in your bash, your installed bash is executed. But if instead run ./bash, the executable bash file in the current directory is executed. So run ./bash.

Welcome to your brand new bash!

Attach the debugger To attach a debugger to the running bash, you need to config launch.json file of VSCode. It’s super easy. Just follow this instruction:

This is my launch.json file:

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        { 
            "name": "(lldb) Attach",
            "type": "cppdbg",
            "request": "attach",
            "program": "${workspaceFolder}/bash",
            "processId": "${command:pickProcess}",
            "MIMode": "lldb"
        }
    ]
}

After that, the only thing you need to do is running the debuger.

Once the debugger is attached to the running bash, you can add a breakpoint, watch variables, executing the code line by line,…

Connectional AND vs Conditional AND

I made the running bash to run these two commands and by adding a breakpoint and checking variables while the commands were getting executed, I tried to understand how bash evaluates them.

[[ A == B && ls || cd ]] 

[[ A == B ]] && ls || cd

To save your time, I want to show you where you should add your breakpoint. shell.c is the bash entry point ( it’s where you can find the bash main() function ). main function calls reader_loop function that is in eval.c. This function waits till you enter a command in bash after parsing it and building a command object, sends it to execute_command in execute_command.c file and from there the command is sent to execute_command_internal in the same file. In the scope of this function, there is a variable called command which is of command type ( the definition in command.h ) and it contains the parsed command entered into bash by a user. the command type is really interesting. It is a struct with 4 general-purpose fields and one union, which represents details of command according to the command type.

/* What a command looks like. */
typedef struct command {
    enum command_type type;    /* FOR CASE WHILE IF CONNECTION or SIMPLE. */
    int flags;            /* Flags controlling execution environment. */
    int line;            /* line number the command starts on */
    REDIRECT *redirects;        /* Special redirects for FOR CASE, etc. */
    union {
        struct for_com *For;
        struct case_com *Case;
        struct while_com *While;
        struct if_com *If;
        struct connection *Connection;
        struct simple_com *Simple;
        struct function_def *Function_def;
        struct group_com *Group;
        #if defined (SELECT_COMMAND)
        struct select_com *Select;
        #endif
        #if defined (DPAREN_ARITHMETIC)
        struct arith_com *Arith;
        #endif
        #if defined (COND_COMMAND)
        struct cond_com *Cond;
        #endif
        #if defined (ARITH_FOR_COMMAND)
        struct arith_for_com *ArithFor;
        #endif
        struct subshell_com *Subshell;
        struct coproc_com *Coproc;
    } value;
} COMMAND;

For example, when you run this command:

[[ A == B ]] && echo 1 || echo 2 

the parser builds a command object like this:

Back to the question with which we started this section when the entered command is:

[[ A == B && ls || cd ]] 

The bash parser generates this command and passes it down to execute_command.:

cm_cond means this command is a of cond_com type. By looking at the definitaion of this structure:

typedef struct cond_com {
    int flags;
    int line;
    int type;
    WORD_DESC *op;
    struct cond_com *left, *right;
} COND_COM;

we learn that:

left and right are of cond_com type.
type can be any of this values:

#define COND_AND    1
#define COND_OR        2
#define COND_UNARY    3
#define COND_BINARY    4
#define COND_TERM    5
#define COND_EXPR    6

So it is a tree. I’ve drawn this tree to make it easier what the parser has generated:

But when you enter:

[[ A == B ]] && ls || cd

the parset generates this command object:

The first difference you have probably noticed is the value of the type field. This value shows that the union part of the command structure represents a connection structure which is:

/* Structure used to represent the CONNECTION type. */
typedef struct connection {
    int ignore;            /* Unused; simplifies make_command (). */
    COMMAND *first;        /* Pointer to the first command. */
    COMMAND *second;        /* Pointer to the second command. */
    int connector;        /* What separates this command from others. */
} CONNECTION;

A connection command has two sub-commands, first and second.

I have drawn what the parser generates:

By continuing debugging, we will see that how a connection command gets evaluated is different from how a cond_com command does. Actually, cond_com has a tree structure ( left node, right node and op ) and is made of the expression according to the Operator Precedence table, but connection commands are more like a list ( it has first and second sub-command ) and gets evaluated from left to right given these two principles:

command1 && command2 Command2 is executed if, and only if, command1 returns an exit status of zero.
command1 |│ command2 Command2 is executed if and only if command1 returns a non-zero exit status.

In our example:

[[ A == B ]] && ls || cd

[[ A == B ]] is evaluated. It is false, so according to principle #1 ls will be ignored.
Because the result of [[ A == B ]] && ls was false, according to princple #2, cd will be executed

But what about the other example:

[[ A == B && ls || cd ]]

According to the generated tree, the expression is made of two sub-expression with the same precedence, so they gets evaluated from left to right: a. exp1: A == B && ls b. exp2: cd
exp1 is made of two sub-expression with the same precedence, so they gets evaluated from left to right: a. exp1.1: A == B b. exp1.2: ls
exp1.1 is false. So the exp1 is false.
exp2 gets evaluated.

As you see, the result of both of these two examples are the same.

Summary

In spite of my first guest, &&/|| in a conditional expression is not the same as &&/|| in a list command. They get parsed and evaluated differently, but most of the time, the results are the same.