ast: `command` has unexpected output when part of arrays.

Nor are we able to moderate the increasingly bitter debates that are going on here.

There is only one person here contributing to that, ban @jghub for being a toxic spammer and the issue will vanish.

We ask both sides respectfully to find their own spaces to continue the work.

We had a perfectible working space here already, please fork the old bitrotten code to another repo.

I don’t know the history of this repo but IMO when there is this much animosity between two camps in an open source community then forking is the civil thing to do.

I stand by our decision to revert this repo to ksh93u+ (2012) and I wish the best of luck to both ksh-community and ksh2020.

AT&T is not able to actively maintain this project, so we need both new communities to fork this repo and continue development elsewhere.

Using eval on arbitrary input is generally not safe and does not at all accomplish what command

of course not. nobody said so. eval and command have nothing to do with each other. you hit a general problem in that $cmd (where cmd holds whatever constructed expression/command) does not in general achieve what you naively might expect: execution of the string value as if you would have typed the same text at the command line. eval $cmd does that. that’s what @hyenias was suggesting and I agree that he is right.

does. Please read the posix spec and reflect upon it until you understand why you are so wrong. As a hint, in my actual script I use command -p which results in the same issue.

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/command.html

I know what the command builtin is for and what it does, thank you very much (that question was mostly at the heart of the incredible #1445, by the way).

what you see (difference between $cmd and eval $cmd) is not specific to the occurrence/using of the command builtin in your “command string” $@. what is specific to command being part of the $cmd string is that it seems(…) that in your special example $cmd and eval $cmd should yield the same (and this being the naively expected) result and that this might be a ksh bug. but what you specifically want to achieve in your script/use case is not relevant to the actual problem/question.

You ever meet that person that says a lot of things without conveying any real information, then proceeds to hammer at it until everyone else leaves out of frustration ultimately killing whatever activity that was occurring before they appeared? That is you. Words can’t express how much disappointment I have in what you accomplished here.

I repeat: stop ranting. please spare me that. stay to the facts. read #1464 and #1466 if you care what actually has happened (or read through a ton of older issues documenting what has gone on here for a couple of years).

and also realise what has not happened: nobody took krader’s “baby” (ksh2020) away from him. he just is no longer allowed to foster it officially in the ATT/AST repository. this is a good thing in my view. if this development is bad in your view, you might tell that to krader and ask to cooperate with him on ksh2020 in a fork.

several people, me included, believe that another road should be taken for ksh93. in another fork. we will try that.

the problem never was the sole existence of ksh2020 or krader’s questionable approach or insufficient suitability to modify the ksh93v- code base. the latter only explains, why ksh2020 is, what it is today: inferior to ksh93u+. if ksh2020 would have been “just another project on github” no harm would have been done.

but the problem was that there was a clear strategy to establish ksh2020 as “the” ksh everywhere no matter what and (wrongly) sailing under the ATT/AST flag was instrumental to that effort. that did harm (by displacing ksh93u+ completely in some distros, replacing it by a ridiculously buggy allegedly “stable” release in the fall of 2019) and that harm has now been stopped it seems. I am happy about this development. if a ksh2020 package appears in distros beside the ATT sanctioned ksh93u+ release (or a new ksh93u+ upstream incorporating incremental bug fixes etc) I am very comfortable with the situation. the more so, since users then could very easily compare the two and find out what they want rather than being force-fed ksh2020.

there is now a clear statement by the ATT/AST team that the official last stable release of ksh is ksh93u+. this will ensure long-term availability of that release (and subsequent bug-fix releases, hopefully, if we succeed).

and for the second time: I propose to leave it at that since you won’t convince me and I won’t convince you. other readers will make up their own minds…

@orbea: As I am new to ksh, I cannot speak towards the possible nuances of command and its related alias. However, if you utilize eval in front of "$@" then it should work as expected.

eval "$@"

Additionally, one can use whence to print the path of any command. Overall, I do not feel that if all the other shells do it then ksh93 must without investigating as to why ksh93 was created in such a fashion. To me the eval --man string seems to be created for such a desired action.

eval is a shell special built-in command that constructs a command by concatenating the args together…