| Summary: | ksh-compatibility for …/completion/git-prompt.sh | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Elmar Stellnberger <estellnb> |
| Component: | RPM Packages | Assignee: | Mageia Bug Squad <bugsquad> |
| Status: | NEW --- | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | Normal | CC: | lewyssmith |
| Version: | Cauldron | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | git-2.41.0-1.mga9.src.rpm | CVE: | |
| Status comment: | |||
| Attachments: |
git-prompt.sh.patch (crtd. by diff -u)
git-prompt.sh.patch (created by diff -u) |
||
|
Description
Elmar Stellnberger
2024-01-31 21:49:01 CET
Created attachment 14320 [details]
git-prompt.sh.patch (crtd. by diff -u)
Created attachment 14321 [details]
git-prompt.sh.patch (created by diff -u)
Oops, there has been an old/wrong diff in the upload directory.
Attachment 14320 is obsolete:
0 =>
1 Thank you for your interest. 'git-prompt.sh' is in package 'git-core', SRPM git. "most shell scripts called from /etc/profile.d are ksh-compatible" How do you know? Why did you choose this particular shell script to make ksh compatible? What about the many others? One bug per script? Or a general request to ensure all our scripts are ksh-compatible - accepting that most probably are, since it claims to be essentially Bourne Shell (not Bash) compatible. ksh says it is code heavyweight, but claims to be fast. From Wikipedia: "a number of free and open source alternatives were created. These include pdksh, mksh, Bash..." implies that Bash itself poses as a ksh alternative. Severity:
normal =>
enhancement As far as I remember the git-prompt.sh was the only .sh autorun-shell script that needed patching. All other scripts as written for sh or bash work with ksh the like. Mostly certain input redirections, numeric for loops and array constants need rewriting; otherwise you can reuse existing shell scripts by ksh more or less without applying any changes. Thank you for this clarification. "the git-prompt.sh was the only .sh autorun-shell script that needed patching" Why does this particular script interest you? Well, I am using git for several projects like index2web, but the main reason is that you would either need to disable it for ksh explicitly or have a patch done for it (Which was in my case more easy and straight forward to do, since I guess also Mageia's developers don't want to write and maintain a separate .kshrc in addition to a .bashrc. There is just one line in git-prompt.sh (using an array constant) that asks for what shell is running, all the rest works with any of the modern shellings (dash, bash, ksh). ). I have just tested it: An 'echo "Hellow world!" written into /root/.bashrc gets also executed if you invoke "> ksh" (and /etc/bashrc executes /etc/profile.d/* in turn by a respective for loop, wherefrom git-prompt.sh gets invoked/called). If you wanna have the same .*rc-file to be executed by bash/dash/the_sh-link and ksh my basic preference was to call it ".profile" so that anyone can see without test/doc-read that it is supposed to be executed by anything for written script like found by a glob of /etc/profile.d/*.sh (BTW man bash/ksh + 'G'-letter-press and PageUp shows you the supported names for ~/.*rc\/autoexec-files the given shell ought to search and execute for on a startup). man bash, 2x{/~/.profile}: "... --login option, it first reads and executes
commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands *** from the first one that exists and is readable ***."
... so guess you can put bash-specific startup-code into ~/.bash_profile, but if you want to have common code being executed by both ksh, bash/dash/sh you will need to invoke ~/.profile explicitly fromout of ~/.bash_profile.
¡Having put a respective 'echo' into /etc/profile and /etc/bashrc as well, I am having to come to the same conclusion that it behaves with the likewise-named /etc-stuff the same as it behaves with ~/&/root-stuff respectively: If *bashrc has already executed it doesn't automatically go for *profile-stuff:(as /etc/bashrc under Mageia/RedHat claims it would go - so possibly an documentation error!): (/etc/profile.d/* is well-behavedly executed by an explicit call in /etc/bashrc on the contrary)
So to put it easy, don't waste an own day with the startup-behaviour of different ‘U’nix-shells, just consider what will make a program-start without error message of the stuff Mageia is currently doing a ship for. - that is get a git-compliant patch for git-prompt.sh if you ask me for (or have my contact called "Elmar Stellnberger <estellnb@paradisetec.org>" - yes, I have just registered and preferred the .org. - why not have another primary intent than money in making good technique?!:)) ).
As far as I see it on my Mageia-i686 machine now the first line (which is a comment) of /etc/profile and /etc/bashrc say that you would be in the respective contrary/other file than you are! - and the variable loginsh=1 set in bashrc ought to prevent a double-execution of the scripts in /etc/profile.d/* fromout-of /etc/profile (Maybe the person who confounded it had invoked vim without -pn). At least that (referring to the text in-between the ¡...! Comment #8) was the way I am having encountered it with bash-v5.2.15 on an updated Mageia 9. I know that previous bash-versions were not as orthogonal (according to Niklaus Wirth a desirable attribute for a programming language*) as it now is (exemplum dato: myfiles=*.sh was assigned as it would be a literal myfiles="*.sh" in previous versions, very annoying since a $(bash -c 'echo *.sh') would mess up spaces and thus make an own for loop required instead (which btw. ʼs gonna save your machine from another fork)). So as it was not as orthogonal before, the loginsh=-variable may have been needed for elder (as (I remember) the original bash-version shipped by Mageia 9) because I suppose it *could* have executed both files implicitly without asking /etc/*profile to be 'sourced' ('.'-command) by /etc/*bashrc. Do your own 'science' if you like, and don't ask for "* Whether I consider non-orthognal behaviour an error (design/programming) - I do! - and once a little time it was said I would prefer the word 'congruent' instead of 'orthognal' when it comes to a language". Elmar: Please suggest how your revised script can be used to confirm it works like the original one. In what circumstance is it used? Automatically, or by some specific user action? |