Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]
On Sat, 2021-04-10 at 22:12 +0200, Joerg Schilling via austin-group-l at The Open Group wrote: > where ??? what is that? I don't know if this is what Jan was thinking of, but "where" exists on Windows and is equivalent to "which" etc. there.
Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]
"Jan Hafer via austin-group-l at The Open Group" wrote: > For a short recap why: There are `which, type, command, whence, where, > whereis, whatis, hash` used in shells. Worse, the semantics of `which` > is shell-dependent. which is a csh script and unrelated to Bourne or POSIX shells. It therefore cannot give useful results in a standard shell environment. Even worse: On Linux, "which" may be a program with different behavior. typeis built into the shell since 1976. What problems do you have with it? command is POSIX standard. What problems do you have with it? whence is a ksh specific command and thus non-portable where ??? what is that? whereis does not exist on a typical UNIX system whatis is a command that behaves like "man -k" hashis POSIX standard, it allows to query all hash entries or to add a potential hash entry. > As for `command -v`: > It is not possible to know the path of the executable without executing > it. This is however slow, since the shell environment has the paths in > memory or it is even cached. It can also have potential unexpected or > dangerous side effects, since command behavior (without arguments) and > command arguments can be deviating. This is not correct. "command -v" does not execute the command. It rather imitates the PATH lookup procedure without executing the command. > 1. Are there plans to allow introspection to the shell environment as to > prevent failures and enforce basic semantics of words? > I am thinking of ways to differentiate 1.aliases, 2.functions, > 3.builtins and 4.executables in and not in $PATH both machine and > human-readable where sufficiently simple (otherwise human readable). > This list may be incomplete. This does not seem to be related to the statements you made above. If you like help, you could make it easier if you could explain more in depth what you like to do and what exact problems you have. Jörg -- EMail:jo...@schily.net Jörg Schilling D-13353 Berlin Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]
Date:Sat, 10 Apr 2021 23:08:40 +0700 From:"Robert Elz via austin-group-l at The Open Group" Message-ID: <20226.1618070...@jinx.noi.kre.to> Now to add to something I said in the previous reply (so so the rest of the audience here don't think I have suddenly changed views...) This message (unlike the previous one) has nothing to do with your message, only mine. | One of the features of sh is that a | name can be an alias, a function, a built command, and several different | filesystem commands, all at the same time. It is neither possible nor | desirable to change that. Actually, it would be possible, and highly desirable, to change that, but in a limited way, by simply deleting aliases. Then there would be one less thing a word could be.But I seem to be in a minority with this desire (but apart from "well they exist, so we should document them" no-one has supplied any good reason for keeping aliases.) kre ps: to make this perhaps a little relevant to the thread, don't forget that in shell, a word can also be just a word, it does not have to be any kind of command at all, and it can be difficult (if not impossible) to look at a script and tell. Consider this simple example read cmd $cmd echo foo What is "echo" there?If your answer doesn't depend upon what was entered in response to the "read" command, then you're wrong. This ability is useful, but how can you expect a shell to ever parse that script, without running it, and have any idea at all what it means?
Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]
Date:Sat, 10 Apr 2021 11:54:34 +0200 From:"Jan Hafer via austin-group-l at The Open Group" Message-ID: <15c15a5b-2808-3c14-7218-885e704cc...@rwth-aachen.de> | my inquiry is a question about the potential unexpected behavior of the | shell execution environment on names. It is related to shortcomings of | the command utility. I'm not sure I understand. I read the rest of the message, and I couldn't find anything really about any shortcomings, other than perhaps some mistakes in interpretation, and usage. | For a short recap why: There are `which, type, command, whence, where, | whereis, whatis, hash` used in shells. Worse, the semantics of `which` | is shell-dependent. Yes, the prevalence of these things is somewhat of an issue, but there is nothing we can do about that really. People are free to reinvent the wheel (make it rounder). 'which' started life, long long ago, as a csh utility (a script written in csh, for use by csh users). There were enough of them, who grew familiar with using it, that when they switched to better shells (when those became available) they continued to use which. I know that even I do on occasion. This wasn't helped by which (kind of) working even for users of other shells (kind of, in that the original still looked in the user's .cshrc for assistance, despite that not being anything used by the shell the user was using). Since then there have been a myriad different versions of which. Best to forget it now (unless you're still a csh user perhaps). 'type' (which you neglected to mention other than by including it in this list) is the POSIX sh way to do what which was designed for, for csh users, and is what ought be used. 'whence' was a (ksh I think) alternative to which, built into some Bourne style shells, also best now forgotten. (In some of those shells, their whence implementation provides their implementation of 'type' I believe .. but I might be wrong.) 'where' I don't know at all, what's that? 'whereis' is different, it was designed (back in csh days) to tell where a standard utility is located - rather than where a utility of a particular name would be run from for a particular user. It doesn't belong in this list at all, it does a different job. 'whatis' is even further removed, that does man page lookups. 'hash' has an entirely different function, which just happens to sometimes be able to reveal similar information to type (but only sometimes) - it should not really be considered in this list either (though it is more related than whereis or whatis). | As for `command -v`: | It is not possible to know the path of the executable without executing | it. This depends entirely on what information you're actually seeking. It is certainly true that to know for sure whether a particular executable runs or not, an attempt must be made to run it. Only the kernel gets to make the yes/no decision on that, and only an actual exec() (or posix_spawn) attempt will invoke the appropriate checks. (eg: one issue might be that a binary that would run prefectly fine elsewhere, fails on this particular system, because it lacks sufficient resources, a 1GB binary (mostly data) cannot run on a system with 512Mb of ram and no swap space, for example, but would run just fine on the same system if it had 4GB of ram.) But that's not what people usually want to know, what is usually desired is, first, what kind of object is "name" (alias, function, built-in command, filesystem command) and in the last case, what path looks to be where it will be located. If "name" has been executed, we will know what path name was used to do that, otherwise we find an executable looking file called "name" somewhere in $PATH and that's it, so, "command -v" certainly doesn't try to execute anything, but the answer it gives is not guaranteed to be correct (this is true of all of the (relevant) commands listed, none of them will actually execute the command once they have located a path just to verify that it actually works - do do that would need far more info (like a file to compile if looking for "cc") than is present in the arg list of any of these commands. | This is however slow, since the shell environment has the paths in | memory or it is even cached. Sorry, I cannot parse that sentence in a way that makes it at all relevant to what you seem to be saying. | It can also have potential unexpected or | dangerous side effects, since command behavior (without arguments) and | command arguments can be deviating. Yes, exactly, that's why it is never done. However, if the user has previously executed the command, and now wants to know what file was executed (say the command dumped core, and the user needs the binary to use with a debugger and the core file, so needs the path name of the binary) then that information can be made available. But no shell (or stand-alone command) is ever going to attempt to run
[Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]
Dear Ladies and Gentlemen, my inquiry is a question about the potential unexpected behavior of the shell execution environment on names. It is related to shortcomings of the command utility. Related page for command utlity semantics: https://pubs.opengroup.org/onlinepubs/009604599/utilities/command.html Take for example this question with high activity: https://unix.stackexchange.com/questions/85249/why-not-use-which-what-to-use-then and this answer gives a relative good POSIX shell history: https://unix.stackexchange.com/a/85250/273935 For a short recap why: There are `which, type, command, whence, where, whereis, whatis, hash` used in shells. Worse, the semantics of `which` is shell-dependent. As for `command -v`: It is not possible to know the path of the executable without executing it. This is however slow, since the shell environment has the paths in memory or it is even cached. It can also have potential unexpected or dangerous side effects, since command behavior (without arguments) and command arguments can be deviating. 1. Are there plans to allow introspection to the shell environment as to prevent failures and enforce basic semantics of words? I am thinking of ways to differentiate 1.aliases, 2.functions, 3.builtins and 4.executables in and not in $PATH both machine and human-readable where sufficiently simple (otherwise human readable). This list may be incomplete. 2. In an ideal scenario the semantic of a word can be make constant, so no other script or shell invocation running afterwards can change it (this would compare to best practices in compiled languages and can be cheaply analyzed before execution of a script). What is the POSIX model for static settings and behavior, which should not be overwritten during execution of the operating system? Does POSIX have any opinion or recommendation how to make SHELL scripting robust? Sincerely, Jan Philipp Hafer PS: I am not able to view the current draft status after email confirmation here https://www.opengroup.org/austin/login.html As I understand it, How frequently are credentials+email subscriber status information synchronised between the file hosting server and the general server?
