Programming

well, the foundation has been laid down for the next phase of tpsh development. Branch ‘parserlexer’ is basically setup to deal with the changes in tpsh_parse, tpsh_lex, and the switch from singular command line execution to enqueued command execution.

The new quote handling is actually quite a bit better, if buggy for now. The sh_eval() functions mostly become dead weight; coupled with the behaviour changes in tpsh_{parse,lex} behaviour the source, ., and eval built-ins (and anything relaying on them) are temporarily broken; as is tpsh -c ‘cmdstr’ until things are further integrated. Pipes also no longer work, since the command resolution doesn’t know how to deal with the command queue yet lol. Fixing 1 subroutine should will fix most breakages.

The idea is more or less that a command like

$EDITOR -o f1 f2 f3; cat f1 f2 f3 | sort -args | sed 's/x/y/g' > /tmp/q

becomes this:

     ( ['vim', '-o', 'f1', 'f2', 'f3'],
       ['cat', 'f1', 'f2', 'f3, '|'], 
       ['sort', ',-args', '|'], 
       ['sed', 's/x/y/g', '>', '/tmp/q'] )

and the trailing ‘|’ symbols would be used to indicate that the current element should be joined with the next (in a non technical sense that is) until the end of pipes is reached; recreating the pipeline (in so far as what happens).

The line is parsed into tokens, then analyzed and formed into a more interesting set of elements like the above array of array references; where the array refs are the argument vector (argv) of the commands to be passed onto pexec() or other suitable function. Previously the line was just parsed and dropped onto resolve_cmd() to figure out if it’s a pipe based, i/o redirection based, built-in, or external command; based on the scalar line or argument vector resulting from expansions.

the master branch remains the stable line for now until this topic branch is finished with.

It’s been a rather slow day, but somewhat productive (only about 10 or 11 commits :@). My families made sure that I’ve had a throbbing headache most of the day… rat fuckers! But at least there is some work to show for it. tpsh now has a concept of $PATHEXT based on cmd.exe’s %PathExt% variable.

Windows is ruled by file extensions, while UNIX could care less about them; so really one of the few good things about Microsoft’s cmd.exe is you can tell it what file extensions should be “understood”, i.e. so you can type ‘notepad’ instead of ‘notepad.exe’. Since tpsh is modeled after the standard Unix sh, it’s mostly oblivious to file extensions: it cares about names. However it is virtually _impossible_ to use Windows from the CLI level without implementing something like PATHEXT or typing yourself into a nightmare (winxp/cmd.exe is actually good at making you do that, compared to a unix/sh).

For better compatibility with a Windows environment, tpsh now implements it’s (my) own concept of the feature, complete with a ‘pathext’ option (default on) to toggle the functionality. The main reason tpsh does this, is so I can type ‘gvim’ when I mean ‘C:Pathtogvim.bat’, the fact that I’m used to typing ‘vim’ is aside the point lol. (I rarely use gvim off win32 b/c of diffs between nt and unix cli)

About the only time I use file extensions is when forced (Win32), when ideal (.zip, .tar, etc), when saving text with CRLF for new line indicators (notepad friendly .txt), multimedia files (.png, .ogg, etc), or when deploying crap to a Windows machine lol. So it’s not an important thing for me; just a time saver.

Another thing I sorted out is what I call the “hash separator” for environment variables. UNIX shells by convention separate values like $PATH with a ‘:’, e.g. ‘/bin:/usr/bin’, but DOS and related bastards use ‘;’ for things like %PATH%, e.g. ‘C:Windows;C:WindowsSystem32’. Because many older operating systems use a ‘letter:path’ style for paths anyway, there is no universally portable default setting. Since virtually all operations involving a variables like PATH, CDPATH, and ENV (an extension used in tpsh, which I’ve never seen another shell use) involve a hash table, I call the mark the ‘hash-sep’ for short. One of today’s changes was exposing the hash-sep directly to the user.

The default hash-sep is ‘;’ under MSWin32, DOS, and OS/2 and ‘:’ otherwise, I’ve no clue what the hell VMS uses and don’t have access to it, so no worries yet ;-). Whenever the user changes the HASHSEP environment variable, the next time an operation that relies on it (basically hsplit(), short for hash-sep split()) the shell compiles it down to a suitable regular expression to save time on future commands.

setenv HASHSEP '/'
rehash

the rehash will cause ‘/’ to compile via qr for to speed up later splits; and due to the change of hashsep, causes the internal cache of $PATH to switch from the default ‘:’ or ‘;’, to ‘/’, which is probably not something anyone wants to do, but being able to fiddle with it can be useful for scripting reasons ^_^. Not to mention the fact that it makes concatenating things like PATH/CDPATH settings more portable when the environment requires something different.

Another bit of today’s work, was setting it up so that the history built-in now displays the correct line numbers. I want to setup builtins to save/load data from HISTFILE; so that command history is not lost between sessions – I’ve always had a bit of an itch about how most shells deal with it; wonder what tpsh might do hehe. Not sure about the $LINENO yet, I never really use it in scripting or interactive usage that much: will probably take the single unix specification into consideration on $LINENO.

If I didn’t have to so much crap for tomorrow, I could probably have half the manual done tonight and still get to bed before 0600 local. But no…. work early, work long, to be driven nuts after work, and probably end up PTFO instead of coding the night way.

my idea of a great vacation: a Ferrari, laptops, solar panels to power them, hot date, and a tropical island with a sunny beach 😉