@JeffSchaller, re. unix.stackexchange.com/posts/645927/revisions , there's nothing Zsh-specific there either. POSIX refers to C for $(( )) and there's no chained comparisons there. And while the question had (( )), I'd be reeeaally surprised to see a shell where $(( )) and (( )) did the arithmetic by different rules.

@ilkkachu fair enough; I'd be OK with removing all the shell-specific tags, then, or leaving only the shell that's explicitly in use

(though I'd rather list the shell that's in use, since I'm not sure it applies to any & every shell, off-hand)

Quote of the day:

> The bash shell would obviously be able to run the above script, but if you want something slightly longer and non-portable, you could write

" if you want something slightly longer and non-portable"

That's brilliant, @Kusalananda! :D :D :D

source: unix.stackexchange.com/a/645970/22222

@terdon Yeah, the array syntax in bash is a bit verbose.

:-)

If your system doesn't have bash you should consider getting a new system

taking random shots at another shell, one that people commonly use because it's the only one they know, and over a few characters. yep, real classy.

@jesse_b OpenBSD doesn't have bash (by default) :-)

I mean, if this was codegolf, it would make sense. But if it was, you could use [[ ]] && to golf it shorter than the sh version

As for the array syntax being absolutely hideous, wasn't it from Ksh?

@ilkkachu So it was. It doesn't make it better though. And I didn't say anything about bash being bad or that the syntax was awful in any shape or form. Only that the array syntax was wordier. That was 50% of what I said. The other part was that it was non-portable. Which any shell script written for a particular shell is.

In fact, I use the named arrays in bash scripts that I myself write for work, when I have to use them, which I do sometimes.

@ilkkachu Let me know what part of the text was not correct.

@ilkkachu I'll take your comment to heart though and remove the wordy if and then and fi and use a short-circuit statement instead. That absolutely makes sense here.

@ilkkachu There were no shots taken! I read that as just poking fun at all non-POSIX shells. This is one of the rare cases where the POSIX syntax is actually simpler and more elegant than what is offered by more advanced shells so it's true that the bash version is just slightly longer and less portable with no apparent benefit. I certainly didn't read it as any sort of attack on bash.

@Kusalananda the attitude.

I... really think you are reading a lot into this.

Like I said, you're commenting on a few characters length difference, which shouldn't really matter. And it reads like pretty much saying the asker shouldn't be using Bash.

@ilkkachu Why would it read that way?

ok, let me ask this way: why would it matter that the other version is slightly longer?

It doesn't, of course. It just is slightly longer and it is less portable. That isn't an attack, it is a statement of fact.

Just to be clear: I use bash and only bash and always bash.

@ilkkachu I'm sorry to have offended you over my choice of wording, and I recognize that this offense could be part of the fallout from a few days ago when we had another disagreement (over something that I've honestly have forgotten). I'm sorry about that too and I can only say that I don't really want to do word fights with anyone. I'll change the text of my answer.

Probably for the best. And I'm sorry I brought it up. It just made me smile, but if others are seeing it as an attack, then editing it out seems like a good idea.

I mean, more than length, the difference between using $@ and arrays would probably matter more if someone were to be familiar with one but not the other

sure, $@ is standard, but for people who might have come from other languages, it might also be a bit obscure

Of course. I would guess that is precisely why Kusalananda included the second version instead of just giving the, as you say, more obscure sh one.

I am vaguely aware of the set -- *; for p; do ... done idiom, but I don't think I've ever actually used it in my life.

and like I said, if we're about code golf, we could take the version using $@, replace the case with [[ ]] && and come with a golfing win for Bash/Ksh

Well, the answer has been edited to be more neutral.

@Kusalananda I'm not exactly sure why that choice of words rubbed me the wrong way. It just... did. I don't know, maybe it just sounded... negative? I'm not sure if I can explain it any better.

@ilkkachu I'll also commend your take in your answer. That's good. Assuming the paths ore not manually ordered that is.

Ooh yes, that's a neat approach! @ilkkachu I assume locales and fancy unicode and stuff will be completely irrelevant since no matter what, they will be sorted in some way or another and the subdirs will always be under the parents.

Maybe change to sort paths.txt | awk ...?

I was going to say I'd also rather have someone shooting holes at that instead of discussing word choices.

Ah in that case, I will point out that it will fail if any paths have newlines.

And no, I don't care that this would mean that they can't be usefully stored in a text file in the first place :P

More seriously, do you need the -v last=""? GNU awk at least won't complain if the variable isn't set on the first iteration. Maybe others will.

yeah, the input format makes those impossible

meh, maybe not.

Seems fine in the ones I have available, at least:

terdon@tpad foo $ sort paths.txt | awk 'last && last == substr($0, 1, length(last)) { next; } { last = $0; print }'
/a/b
/a/e/f/g/h
/a/e/f/g/m/n/o
/a/e/f/g/m/n/p
terdon@tpad foo $ sort paths.txt | mawk 'last && last == substr($0, 1, length(last)) { next; } { last = $0; print }'
/a/b
/a/e/f/g/h
/a/e/f/g/m/n/o
/a/e/f/g/m/n/p
terdon@tpad foo $ sort paths.txt | nawk 'last && last == substr($0, 1, length(last)) { next; } { last = $0; print }'
/a/b
/a/e/f/g/h
/a/e/f/g/m/n/o
/a/e/f/g/m/n/p

Huh. Even busybox is fine with it:

$ ln -s /usr/bin/busybox awk
$ sort paths.txt | ./awk 'last && last == substr($0, 1, length(last)) { next; } { last = $0; print }'
/a/b
/a/e/f/g/h
/a/e/f/g/m/n/o
/a/e/f/g/m/n/p

"An uninitialized value shall have both a numeric value of zero and a string value of the empty string." -- well, there it is.

Ah, perfect. So it's POSIX.

ah, yes, the obvious failure case: /foo and /foobar ;)

I had this nagging feeling that I wasn't sure if it works :D

incidentally, I think all the other answer on the page get that wrong, too.

Ah yes. Stupid substrings

@ilkkachu Aha! So, add a trailing / if it's missing?

that's what I was thinking, yeah

just hope there's no non-normalised paths in the input... (e.g. /foo//bar or /foo/asdf/../bar)

@ilkkachu As long as the paths are consistent, that should be no worry.

well, yes

lol, I just got an introduction splash page when I went to the review queues

apparently this:

well, I hope you read the instructions closely :D

@ilkkachu There is a super-obnoxious edge case for all of those answers: / and // are totally unrelated normalised paths

Not that that's ever likely to come up, but...

it'd require having / itself in the list, so it could match //something, right? yeah, that sounds like a quite obscure corner-case.