<oriansj>and I just realized we did a standards violation with kaem <oriansj>we are supposed to be setting $SHELL if it doesn't exist and overriding it if it does <nimaje>man environ says 'SHELL The full pathname of the user's login shell.' on my system, that sounds like it should only be set by shells that are executed as login shell <stikonas[m]>It probably doesn't matter, kaem will never be fully POSIX compatible <oriansj>which I guess could even be guile or python if one wanted <nimaje>"the user's command language interpreter" so the users login shell, well probably only login should set it <oriansj>stikonas: yep just 21 lines total. 7 to override, 4 to determine/store shell name and 10 to add SHELL if it doesn't exist <oriansj>nimaje: I can see the value in that perspective and I can see the appeal for those writing a shell. <oriansj>but if you change shells during your interactive use, should not SHELL change to accurately reflect the shell one is currently using? <nimaje>is there another valid usecase for SHELL than for terminals to know what shell they should spawn for the user when they aren't given some command to run? <stikonas>nimaje: in principle you can use it if you share a script between bash and kaem <oriansj>knowing which shell you are in so you can provide the correct commands back to the user. (like Guix, it doesn't need to display the hash command to dash/fish shell users) <stikonas>and you want to hide some features not supported by kaem <stikonas>but I'm not aware of anybody sharing the same file between bash and kaem <stikonas>given that kaem has no support for functions, it's better to just write a separate code for kaem and bash <oriansj>also if one has say echo $SHELL in a script, you would be able to know what shell actually ran your script <nimaje>yeah, that stuff could be useful, but it isn't what SHELL gives you, bash has BASH_VERSION to detect that your script runs in bash and some other shells similar variables <oriansj>nimaje: but BASH_VERSION isn't exported into envp and passed to programs <oriansj>so say a C program can't go look at envp and know: hey the parent shell was bash so the commands the user needs to run are blah or the parent shell was fish and we need to show them something different <nimaje>so, should the variable you propose only set for interactive use or for scripts too? what if some script wants to get some command from stdout it calls? what if the user has written a small wrapper in some other language, but would want the commands for his interactive shell? <oriansj>nimaje: well envp is copied when passed to sub-processes. so keep that in mind <oriansj>So when a command interpreter starts running, it should ensure it knows the SHELL of is envp and set the envp for the commands it calls so that they know who is calling them. <oriansj>interactive use or not withstanding, it is a basic thing to know about the environment you are running in. <oriansj>and perhaps using the environment variable SHELL wouldn't be the correct choice <oriansj>perhaps a new variable like COMMAND_INTERPRETER or something should be the envp variable modified and passed <nimaje>yeah, but some progams want to change that variable, would that be only interactive shells (that would not work for scripts that want to get a command from the program they call) or any command interpreter that uses a language similar to sh, not caring if interactive or not (that would not work for small wrapper utilities), ... <stikonas>in general kaem would probably benefit from reading the whole file into buffer if we want to add next batch of features... <oriansj>nimaje: I perhaps fail to see a valid and useful need to change that variable outside of the very special case of "I am a command interpreter and will be overriding that value for the subprocesses that I spawn" <oriansj>stikonas: kaem is approaching its upper bound of functionality, as one could do a proper shell parser and all the rest and make for a much better shell but it was never intended to be able to drive the whole process to completion <stikonas>yes, I agree that it's approaching it. Especially if we don't want to add more syscalls <stikonas>though possibly stuff like loops or function could be added <stikonas>but on the other hand if gash work gets finished, we can just switch to gash <oriansj>stikonas: well gash is finished(ish); it is the mes.c improvements that are needed and janneke tends to get that stuff done. <stikonas>well, yes, I meant when gash can run on mes (probably by adjusting both mes.c and gash) <stikonas>I think if we build mes-m2 with kaem, then we still need to rebuild mes lib c and mes with mescc and then I think gash might run, so we won't need kaem for tcc and subsequent steps <oriansj>plus if we need to there are also shells which are written in C and could be converted to M2-Planet subset rather easily <oriansj>and an even larger subset should be directly buildable by mescc <nimaje>oriansj: just imagine some program C that supports that envvar and outputs some command to run after it and a user has two command interpreter A and B, prefering A but having a program D that uses C and needs to run the outputted command written in B and some wrapper W that does some stuff around calling C also written in B, now D would want that C outputs the command for B and W would want <nimaje>that C outputs the command for the calling interpreter (in that case A) so which of these conflicting usecases should be supported? (another problem is that programs have to understand the values (TERM is a mess)) <Hagfish>i was hoping for something more than "could be possible", but it's nice to see it mentioned ***stikonas_ is now known as stikonas
<oriansj>nimaje: let me be certain I understand your question. User prefers shell ${A} but also has shell ${B} installed. They Run command ${C} in shell ${A} which needs its output to be run in ${B}. Ok output #!/usr/bin/env ${B} and it'll work fine. <oriansj>(I am a huge fan of being explicit in your dependencies and being honest about your needs) <nimaje>no, the user has two programs, D and W both written in B, D needs to run the command of C and W is some wrapper around C so it would want C to output that command for the calling interpreter (probably A as that is what the user uses inteactively)