#ansistrip from punk::ansi is better/more comprehensive
proc stripcodes {text} {
#obsolete?
#single "final byte" in the range 0x40–0x7E (ASCII @A–Z[\]^_`a–z{|}~).
dict set escape_terminals CSI [list @ \\ ^ _ ` | ~ a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z "\{" "\}"]
#dict set escape_terminals CSI [list J K m n A B C D E F G s u] ;#basic
dict set escape_terminals OSC [list \007 \033\\] ;#note mix of 1 and 2-byte terminals
#we process char by char - line-endings whether \r\n or \n should be processed as per any other character.
#line endings can theoretically occur within an ansi escape sequence (review e.g title?)
#if the child process takes a while to begin reading stdin - the data on stdin between when we stopped the parent chan event handler and when the child gets data,
#seems to stay buffered somewhere. It is then read by the parent, after the child returns. (ie not lost, but out-of-order)
#This can be apparent sometimes even with fast typing upon calling an executable. (e.g occasionally even vim - but seems to be timing based so might only happen first time if at all)
# see scriptlib/stdin_race.tcl etc test files.
#similar problem with python & perl - issue seems to be in libc or OS buffering behaviour for standard channels.
#note that zig (repo/jn/zig/stdin_race) seems to avoid this issue - todo - make zig based binary extension for open/exec?
set rdout [open |[concat $commandlist [list 2>@$wrerr <@$inchan]] [list RDONLY]]
#ansistrip from punk::ansi is better/more comprehensive
proc stripcodes {text} {
#obsolete?
#single "final byte" in the range 0x40–0x7E (ASCII @A–Z[\]^_`a–z{|}~).
dict set escape_terminals CSI [list @ \\ ^ _ ` | ~ a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z "\{" "\}"]
#dict set escape_terminals CSI [list J K m n A B C D E F G s u] ;#basic
dict set escape_terminals OSC [list \007 \033\\] ;#note mix of 1 and 2-byte terminals
#we process char by char - line-endings whether \r\n or \n should be processed as per any other character.
#line endings can theoretically occur within an ansi escape sequence (review e.g title?)
#if the child process takes a while to begin reading stdin - the data on stdin between when we stopped the parent chan event handler and when the child gets data,
#seems to stay buffered somewhere. It is then read by the parent, after the child returns. (ie not lost, but out-of-order)
#This can be apparent sometimes even with fast typing upon calling an executable. (e.g occasionally even vim - but seems to be timing based so might only happen first time if at all)
# see scriptlib/stdin_race.tcl etc test files.
#similar problem with python & perl - issue seems to be in libc or OS buffering behaviour for standard channels.
#note that zig (repo/jn/zig/stdin_race) seems to avoid this issue - todo - make zig based binary extension for open/exec?
set rdout [open |[concat $commandlist [list 2>@$wrerr <@$inchan]] [list RDONLY]]
#ansistrip from punk::ansi is better/more comprehensive
proc stripcodes {text} {
#obsolete?
#single "final byte" in the range 0x40–0x7E (ASCII @A–Z[\]^_`a–z{|}~).
dict set escape_terminals CSI [list @ \\ ^ _ ` | ~ a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z "\{" "\}"]
#dict set escape_terminals CSI [list J K m n A B C D E F G s u] ;#basic
dict set escape_terminals OSC [list \007 \033\\] ;#note mix of 1 and 2-byte terminals
#we process char by char - line-endings whether \r\n or \n should be processed as per any other character.
#line endings can theoretically occur within an ansi escape sequence (review e.g title?)
#if the child process takes a while to begin reading stdin - the data on stdin between when we stopped the parent chan event handler and when the child gets data,
#seems to stay buffered somewhere. It is then read by the parent, after the child returns. (ie not lost, but out-of-order)
#This can be apparent sometimes even with fast typing upon calling an executable. (e.g occasionally even vim - but seems to be timing based so might only happen first time if at all)
# see scriptlib/stdin_race.tcl etc test files.
#similar problem with python & perl - issue seems to be in libc or OS buffering behaviour for standard channels.
#note that zig (repo/jn/zig/stdin_race) seems to avoid this issue - todo - make zig based binary extension for open/exec?
set rdout [open |[concat $commandlist [list 2>@$wrerr <@$inchan]] [list RDONLY]]
#if the child process takes a while to begin reading stdin - the data on stdin between when we stopped the parent chan event handler and when the child gets data,
#seems to stay buffered somewhere. It is then read by the parent, after the child returns. (ie not lost, but out-of-order)
#This can be apparent sometimes even with fast typing upon calling an executable. (e.g occasionally even vim - but seems to be timing based so might only happen first time if at all)
# see scriptlib/stdin_race.tcl etc test files.
#similar problem with python & perl - issue seems to be in libc or OS buffering behaviour for standard channels.
#note that zig (repo/jn/zig/stdin_race) seems to avoid this issue - todo - make zig based binary extension for open/exec?
set rdout [open |[concat $commandlist [list 2>@$wrerr <@$inchan]] [list RDONLY]]
