Strange construct in BASH script file

I don't know. I can add that they *are* exactly the same, but different files i.e. no hardlinks, on MacOS (and they're in /bin not /usr/bin). Check if there are hardlinks to a file: "find /bin -samefile /bin/test"

By the way, as long as you are in Bash, you will not be using either /usr/bin/[ or /usr/bin/test because both [ and test are shell built-ins; Bash uses its own implementation, *not* the binaries in /usr/bin.

Looking at strings within the '[' executable I see, among other things:-

NOTE: [ honors the --help and --version options, but test does not. test treats each of those as it treats any other nonempty STRING.

So, at least on Ubuntu Linux, they aren't identical.

I wonder why they added those versions but I imagine they made [ different so that test didn't diverge from POSIX. More and more Linux is not unix.

Probably the last time I looked at '[' to see it was a link to 'test' would have been on a Apollo Domain workstation ...

It's still that way on FreeBSD's latest release.

? steve@steve /bin $ ls -li [ test

It's got a bit bigger over the years though.

Are they copies or hardlinks? Try: find /bin -samefile /bin/test On MacOS, derived from BSD, they're copies. Probably easier to distribute, and the size doesn't matter anymore.

Obviously, hardlinks. Note that both files share inode 819744 (the first field in the "ls -li" output)

Well, they share the same inode ...

Ok, yes. Obvious if you know what -i does.

Ahh. Thanks. There are in fact quite a few differences in the text. On the Pi, at least, '[' mentions the GPL licence. 'test' doesn't. Doing a diff on 'strings' for the two doesn't show other major differences, though, so I guess they were written together. Maybe 'test' just doesn't have user assistance -- not sure why not.

-- Pete --

There's a man page for those who don't.

I hadn't bothered to look. It can happen, you know.