3 ms·

Sometimes I want a more interactive shell. With the native ability to display graphics and view html and PDFs and other docs, without opening a separate GUI pro

Sometimes I want a more interactive shell. With the native ability to display graphics and view html and PDFs and other docs, without opening a separate GUI program.

chubot 6y ago
Yeah I hope people will build stuff like that on top of Oil. Hopefully this year the embedding story will become clearer, and progress can be made on top. Some notes here about interactive shell ideas: https://github.com/oilshell/oil/wiki/Interactive-Shell https://github.com/oilshell/oil/wiki/Interactive-Shell Some people might think Oil is sort of a text-only or retro project ... but it really isn't, it's a SPEED project. I use shell because it's the fastest to get certain things done. But other things are faster when done with GUIs. Actually I wrote the last 5 or 6 blog posts in https://stackedit.io https://stackedit.io because copying and pasting huge swaths of text and links and images is faster with the mouse! I am a die-hard Vim person for code, but I realized that "thinking and writing" is aided by the mouse and by rich GUIs (but not slow ones, which is hard!). Previewing hyperlinks is also very important.
- skissane 6y ago
  One thing newbies often ask, is why can't they write a shell script which changes the environment or directory of their running shell. The answer, of course, is that you can't, without sourcing it. People also ask the same question about Windows, and even DOS before it; there you actually could do it from a batch file, since CMD.EXE/COMMAND.COM effectively sources all batch files, it doesn't run them in a subprocess – but the same issue occurs if you write a program in some other language than batch, it runs in a subprocess and so can't modify CMD.EXE/COMMAND.COM's environment. (People resorted to some tricks though, like having a BATCH1.BAT call their program, and then afterwards call BATCH2.BAT, and their program modifies BATCH2.BAT on disk). Actually on DOS, there is a way to modify COMMAND.COM's environment – COMMAND.COM installs an undocumented interrupt, INT 0x2E, which you can use to send commands to COMMAND.COM to run. So you can actually modify COMMAND.COM's environment. (Only the root COMAMND.COM installs a handler for INT 0x2E, nested ones do not.) Of course, due to no memory protection, there are also nasty ways of doing this, like modifying COMMAND.COM's memory. (And changing COMMAND.COM directory isn't an issue, since under DOS, the current directory is system-wide, not per-process.) I was thinking, you could do something like "INT 0x2E" in a Unix shell. Create a Unix domain socket, and the shell listens for commands on it to execute. Put the path to the socket in an environment variable which is inherited by subprocesses, e.g. SHELL_CONTROL. Then, a subprocess can inspect and modify the shell's environment, working directory, functions, aliases, running jobs, etc, by reading/writing the Unix domain socket mentioned in SHELL_CONTROL.
  - chubot 6y ago
    Yes there are some ideas discussed here: https://github.com/oilshell/oil/issues/738 https://github.com/oilshell/oil/issues/738 I would call the 2 possible solutions an API or IPC, and what you're describing is basically IPC. The devil is in the details though... I'm interested in a prototype :) A consumer of the interface will help shape it.

Sometimes I want a more interactive shell. With the native ability to display graphics and view html and PDFs and other docs, without opening a separate GUI program.

chubot 6y ago

Yeah I hope people will build stuff like that on top of Oil. Hopefully this year the embedding story will become clearer, and progress can be made on top. Some notes here about interactive shell ideas: https://github.com/oilshell/oil/wiki/Interactive-Shell https://github.com/oilshell/oil/wiki/Interactive-Shell Some people might think Oil is sort of a text-only or retro project ... but it really isn't, it's a SPEED project. I use shell because it's the fastest to get certain things done. But other things are faster when done with GUIs. Actually I wrote the last 5 or 6 blog posts in https://stackedit.io https://stackedit.io because copying and pasting huge swaths of text and links and images is faster with the mouse! I am a die-hard Vim person for code, but I realized that "thinking and writing" is aided by the mouse and by rich GUIs (but not slow ones, which is hard!). Previewing hyperlinks is also very important.

skissane 6y ago
One thing newbies often ask, is why can't they write a shell script which changes the environment or directory of their running shell. The answer, of course, is that you can't, without sourcing it. People also ask the same question about Windows, and even DOS before it; there you actually could do it from a batch file, since CMD.EXE/COMMAND.COM effectively sources all batch files, it doesn't run them in a subprocess – but the same issue occurs if you write a program in some other language than batch, it runs in a subprocess and so can't modify CMD.EXE/COMMAND.COM's environment. (People resorted to some tricks though, like having a BATCH1.BAT call their program, and then afterwards call BATCH2.BAT, and their program modifies BATCH2.BAT on disk). Actually on DOS, there is a way to modify COMMAND.COM's environment – COMMAND.COM installs an undocumented interrupt, INT 0x2E, which you can use to send commands to COMMAND.COM to run. So you can actually modify COMMAND.COM's environment. (Only the root COMAMND.COM installs a handler for INT 0x2E, nested ones do not.) Of course, due to no memory protection, there are also nasty ways of doing this, like modifying COMMAND.COM's memory. (And changing COMMAND.COM directory isn't an issue, since under DOS, the current directory is system-wide, not per-process.) I was thinking, you could do something like "INT 0x2E" in a Unix shell. Create a Unix domain socket, and the shell listens for commands on it to execute. Put the path to the socket in an environment variable which is inherited by subprocesses, e.g. SHELL_CONTROL. Then, a subprocess can inspect and modify the shell's environment, working directory, functions, aliases, running jobs, etc, by reading/writing the Unix domain socket mentioned in SHELL_CONTROL.
- chubot 6y ago
  Yes there are some ideas discussed here: https://github.com/oilshell/oil/issues/738 https://github.com/oilshell/oil/issues/738 I would call the 2 possible solutions an API or IPC, and what you're describing is basically IPC. The devil is in the details though... I'm interested in a prototype :) A consumer of the interface will help shape it.