Changes for debug input/output (hacked)

[rogalmic]

No description provided.

[rocky]

This is closer to isolating the essential changes. It looks like there is still more work to do though.

[rocky]

You've changed the meaning of _Dbg_open_if_tty and set inferior-tty from the tty being read/write to being read only. Why was this necessary?

If for some reason you need a tty for reading, why not create new routines, instead change the behavior of these?

[rocky]

I'm totally confused as to what you intend to do by this?

[rocky]

Why is appending right?

[rogalmic]

This is actually the part that is totally hacked, since i could not figure out what to do with fdi's - I just added the actual file for testing.

So the vscode extension uses 2 named pipes (debugger in, debugger out), they are expected to be separated from debugged script's in/out/err (command line options). I will check soon, maybe the appending is not needed...

[rogalmic]

You are correct, _Dbg_open_if_tty and set inferior-tty should not be touched then.

I am having problems since for example I do not get the idea of "inferior tty". The zshdb debugger has extended terminal support, I am not sure how to implement the named pipe in/out while at the same time not breaking the main functionality. In bashdb case it seemed easier for some reason...

[rocky]

I am having problems since for example I do not get the idea of "inferior tty".

With "inferior tty" I am just trying to follow gdb. See http://visualgdb.com/gdbreference/commands/tty

There are two ways I see we could accommodate changed behavior. One way inside this repository is to add two directories new directories paralleling the command and lib directories, let's say vscommand and vslib, along with adding a new zshdb command option --vs. When that option is set, files in these new directories are read after the files in the current command and lib directories. Any functions that are defined in the new library vslib, such as _Dbg_tty() will overwrite the existing definition of _Dbg_tty() from lib.

Another possibility is just to keep a small set of patches outside and patch the code from those patches. That would work better if you wanted to patch not only for VSCode needs but also for different bash shells but down't want the bloat of the largely common sets of files that occurs among the different versions.