On 16/09/13 18:07, John Colvin wrote:
>
> Ever since watching a friend have his entire /usr deleted by a dodgy
> 'sudo make install', i desperately avoid manually installing to anywhere
> but a dedicated subdir in $home. No root access needed and I actually
> know where everything is =)

In order for users of my PyGTK scripts to not have to risk the integrity of their system (by installing them from my source rather than through their package manager), I go out of my way to make sure that all that is required is for the source directory to be in their $PATH (or alternatively run them with the full path to the executable) in order for them to be usable.  Because Python scripts know the directory where they're installed (as well as where they're run from) it's possible to know where to look for any support files using this data and Python automatically includes the installed directory and its subdirectory when it looks for library packages/modules.

This saves me the bother of having to learn how to make packages for all the different systems out there without asking the user to compromise their system integrity.

Peter
PS I also provide an install script so the users have that option and the location of the root directory for the installation is configurable.

On Mon, 16 Sep 2013 15:51:41 -0700, H. S. Teoh wrote:

> On Mon, Sep 16, 2013 at 09:53:34PM +0200, Adam D. Ruppe wrote:
>> On Monday, 16 September 2013 at 17:04:46 UTC, H. S. Teoh wrote:
>> >It's a miniscule time savings, but it does add up when you're editing a complex command-line pipeline.
>> 
>> You know what would actually be huge for me? The mouse. If you have a 200 character command line, just clicking it would be so nice.
>> 
>> I'm sure there's some ctrl+meta+alt that can do it too, but I don't know my emacs (and readline's vi mode is weak).
> 
> There's a vi mode to readline??
> 
> My ideal, actually, would be to liberate the command-line from its single-line restriction. It would be in insert mode by default, to cater for the common case, but hitting ESC would put it into navigation mode, where you can use vi movement keys to navigate. You could construct the command in a block (almost like a one-off shell script) before committing and executing it.

Do you know about C-x C-e?  If EDITOR is set to "vi" it should open the current command in vi as a temp file, allow you to edit, and when you write and quit it'll execute it.  Not sure if this is Bash only or universal.

On Monday, 16 September 2013 at 23:35:00 UTC, Justin Whear wrote:
> On Mon, 16 Sep 2013 15:51:41 -0700, H. S. Teoh wrote:
>
>> On Mon, Sep 16, 2013 at 09:53:34PM +0200, Adam D. Ruppe wrote:
>>> On Monday, 16 September 2013 at 17:04:46 UTC, H. S. Teoh wrote:
>>> >It's a miniscule time savings, but it does add up when you're editing
>>> >a complex command-line pipeline.
>>> 
>>> You know what would actually be huge for me? The mouse. If you have a
>>> 200 character command line, just clicking it would be so nice.
>>> 
>>> I'm sure there's some ctrl+meta+alt that can do it too, but I don't
>>> know my emacs (and readline's vi mode is weak).
>> 
>> There's a vi mode to readline??
>> 
>> My ideal, actually, would be to liberate the command-line from its
>> single-line restriction. It would be in insert mode by default, to cater
>> for the common case, but hitting ESC would put it into navigation mode,
>> where you can use vi movement keys to navigate. You could construct the
>> command in a block (almost like a one-off shell script) before
>> committing and executing it.
>
> Do you know about C-x C-e?  If EDITOR is set to "vi" it should open the
> current command in vi as a temp file, allow you to edit, and when you
> write and quit it'll execute it.  Not sure if this is Bash only or
> universal.

Bash only AFAIK, although there's probably alternatives for other shells. Nice feature, very useful :)

On Mon, Sep 16, 2013 at 11:35:00PM +0000, Justin Whear wrote:
> On Mon, 16 Sep 2013 15:51:41 -0700, H. S. Teoh wrote:
[...]
> > My ideal, actually, would be to liberate the command-line from its single-line restriction. It would be in insert mode by default, to cater for the common case, but hitting ESC would put it into navigation mode, where you can use vi movement keys to navigate. You could construct the command in a block (almost like a one-off shell script) before committing and executing it.
> 
> Do you know about C-x C-e?  If EDITOR is set to "vi" it should open the current command in vi as a temp file, allow you to edit, and when you write and quit it'll execute it.  Not sure if this is Bash only or universal.

Whoa. My mind is blown.

I'm gonna hafta do this from now on. :) (OK, C-x C-e is so emacs-y, but
I do have $EDITOR set to vim, so I'll deal. ;-))


T

-- 
"I'm not childish; I'm just in touch with the child within!" - RL

On Monday, 16 September 2013 at 22:53:04 UTC, H. S. Teoh wrote:
> There's a vi mode to readline??

yeah, in bash you can enable it with

set -o vi

I've found some little problems with it, though your mileage may vary. One is that terminal escape sequences might mess it up. For example, in my rxvt, if I hit the end key, it uppercases the next few characters: my rxvt sends ^[[7~ on home, which the vi mode sees as 7~. But, in the default (emacs) mode, all these keys work.

So I think the escape sequence is being misinterpreted as a series of user input. On my xterm however, it works correctly.


Another weird thing is when you hit a number, so I hit 3, it says:

me@arsd:~$ tESTING vi mode
<hit 3 now>
(arg: 3) tESTING vi mode

Which I guess isn't that bad, it is just different....

but here's something awesome: if you hit v, it actually brings up the actual vi (probably $EDITOR, since it loaded vim for me whereas my plain vi is elvis) to edit the command line!

That might just be your idea: edit it by hitting esc v.


So you know, I think it is time I give this another try. Time to edit bashrc...

> In fact, now that I think of it, my use cases for C-s has drastically diminished over the years.

Aye, but I agree it is useful from time to time. I've used it on ssh too, or when building or running something like mplayer that just won't shut up long enough to scroll back.

BTW I used to not know about ^Q, so if I accidentally hit ^S, I'd get pissed at it freezing and not know what to do!

> Just enough to be able to render window titles in UTF-8 correctly.

eh, I'm not sure which X function does it, but that's small enough you could just render it as a pixmap and draw it that way. (This is the way gtk and qt do all text!)

On my github, you can also find stb_truetype.d which renders ttfs to little images without dependencies (it is a port of the stb_truetype.h public domain C file). The D api portion is still incomplete but there's enough there to use it, and I *think* I did unicode correctly.

> I see. Thanks for the tip, I'll have to keep that in mind in case I run into similar issues. :)

there's a good chance you'll be ok with a switch/router instead of a hub. I actually got the hub so I could sniff the network traffic from my brother.... but I never actually did any of that and instead set it up as the upstairs hub, so I'd only have to run one long wire from the router downstairs.

But the problem is that hub was kinda slow and would get packet collisions fairly often. A switch, or maybe even a 10/100 hub, would probably work a lot better.

> I ran at 800x600 for many years, before I upgraded to a 1600x1200 LCD monitor.

that's huge! The one I have now is 1280x1024, the biggest I've ever used. (I notice you are using 4:3 too. 4:3 rox.)


> Really? I remember trying it, but the non-ASCII characters came out all wrong.

I might be wrong.

> Speaking of which, have you had a chance to look at the latest breakage with DMD git HEAD yet?

I just did, and it worked, though I had to grab updated druntime and phobos too.

./dmd  -c ~/arsd/terminal.d  -I~/d/wtf/druntime-master/src/ -I~/d/wtf/phobos-master/
# silence is good!
me@arsd:~/d/wtf/dmd-master/src$

> I might just be able to get rid of my GUI browser dependence once and for all. :)

arguably it'd still be a gui, since it'd need to run in graphics mode and all! Just a *great* gui.

I think links can actually be configured to run a svgamodelib helper program to display images one by one in the linux terminal too...

> I do remember that feature in the BIOS, actually. I also remember it was horrifically slow. In fact, I reinvented
> my own text output system in
> assembly which was orders of magnitude faster.

Aye, all BIOS text output was brutally slow, I'm sure just about every DOS programmer did their own text output at one point or another!

In text mode, you just write to segment 0xb800, and in graphics mode what I did was blit some little bitmaps over. Wrote my own bitmap font editor too.


Actually, I recently ported some of my old DOS drawing stuff to D, called image_basicdrawing.d. Does bresenham's line algorithm, ellipses, and bitmapped text.

I haven't put it to github yet though because I'm pretty sure I copy/pasted half that code back in the day and thus aren't sure about the copyright status!


> The first thing I'd do if I were to write a terminal spec is to get rid of the stupid dependence on ESC as the terminal control escape code.

god yes, especially on input. This is another thing (omg back to the roots of this hijack!) that Windows just does so much better.

Raw console input on Windows is delivered as INPUT_RECORD structs:

http://msdn.microsoft.com/en-us/library/windows/desktop/ms683499%28v=vs.85%29.aspx

which is nice and structured. Extensible, unambigious, and a lot less hideous than the mess of input sequences you can get on linux.

I guess it is less efficient over ssh, but it is so much simpler.


Though, an easy fix to the unix thing: make your esc key send it twice. So ^[^[ == user hit esc, similarly to how "\\" is `\`. At least then it won't be as messy. Sending it twice might even be more backward compatible since a lot of unix programs either specifically watch for the second esc, or at least ignore the second one already since that's a fairly common manual workaround for the crappy design.

If I was doing it from scratch, I'd probably say plain input is one byte, escape is either ^[ with ^[^[ the literal esc, or an invalid utf-8 byte like you said, though that might reduce error detection, and anything else is a struct: <ESC>size_of_struct type_of_event event_data....\n (or something).

The data could be binary or ascii, whatever, but this way you could skip it by only knowing the size (unlike the termcap mess on linux), it could embed arbitrary data in there, and is unambiguous.

Another thing that might be nice is to make sure it is all invalid utf bytes, but encoding data that way would get long. But then you could ignore it even if you missed the size - would be nice to recover a broken stream.


I'd do output similarly too. Escape sequences on output aren't nearly as nasty as on input - you probably don't output an esc character most the time - but still they should be structured enough so you can easily ignore unknown ones and be a little more binary safe.

Then you output a png image in that same set too!


> rather than being constantly interrupted by dings and beeps and popups,

i love beeps lol

modprobe pcspkr


> I never leave the title as 'rxvt'; I wrote a little program that writes the escape sequence to change the window title to the command-line args,

I did one of those too (a shell script too lol) but I do it spacially or transiently anyway - my rxvts either live long enough that I get to know them by position on the taskbar, or they are gone so quickly that it doesn't matter.

Another hassle is screen sometimes doesn't propagate that correctly which is annoying too...

> Yeah I should stop talking about ratpoison replacements, and actually go write one. In D. With ranges. :-P

lol ranges

On Tuesday, 17 September 2013 at 00:03:34 UTC, Adam D. Ruppe wrote:
> set -o vi

better yet, edit ~/.inputrc and add

set editing-mode vi

in there. Then it works for other programs that use readline too like mysql! I almost forgot about that file, but there's a comment in there that I added some sequences for rxvt, so sweet.

That file might be a good thing to customize the hell out of.

On Tue, Sep 17, 2013 at 02:03:33AM +0200, Adam D. Ruppe wrote:
> On Monday, 16 September 2013 at 22:53:04 UTC, H. S. Teoh wrote:
> >There's a vi mode to readline??
> 
> yeah, in bash you can enable it with
> 
> set -o vi
> 
> I've found some little problems with it, though your mileage may vary. One is that terminal escape sequences might mess it up. For example, in my rxvt, if I hit the end key, it uppercases the next few characters: my rxvt sends ^[[7~ on home, which the vi mode sees as 7~. But, in the default (emacs) mode, all these keys work.

Well, now that I just learned about C-x C-e in bash, I think I won't need this anymore. :) Just need to set $EDITOR to vim, and off I go.


[...]
> >Just enough to be able to render window titles in UTF-8 correctly.
> 
> eh, I'm not sure which X function does it, but that's small enough you could just render it as a pixmap and draw it that way. (This is the way gtk and qt do all text!)

No kidding! Never knew that. I guess that just shows how b0rken (or antiquated) X11 font handling is. I remember reading through the protocols for it... looks like a valiant attempt at future-proofing, which fell flat because of the unpredictability of what the future might hold. Premature generalization at its finest. :)


> On my github, you can also find stb_truetype.d which renders ttfs to little images without dependencies (it is a port of the stb_truetype.h public domain C file). The D api portion is still incomplete but there's enough there to use it, and I *think* I did unicode correctly.

Interesting! I'll have to check it out sometime.


> >I see. Thanks for the tip, I'll have to keep that in mind in case I run into similar issues. :)
> 
> there's a good chance you'll be ok with a switch/router instead of a hub. I actually got the hub so I could sniff the network traffic from my brother....

lol...


> but I never actually did any of that and instead set it up as the upstairs hub, so I'd only have to run one long wire from the router downstairs.

I still have an unused hub lying around, after replacing it with a wireless router so that my wife doesn't need to constantly plug in stray ethernet cables just to make her laptop work. Never realized collisions can be so bad on a hub.


[...]
> >I ran at 800x600 for many years, before I upgraded to a 1600x1200 LCD monitor.
> 
> that's huge! The one I have now is 1280x1024, the biggest I've ever used. (I notice you are using 4:3 too. 4:3 rox.)

I'm a stickler for 4:3. I *hate* those shortscreen monitors (aka widescreen :-P). It feels like the top got chopped off. I value my vertical real estate!


[...]
> >Speaking of which, have you had a chance to look at the latest breakage with DMD git HEAD yet?
> 
> I just did, and it worked, though I had to grab updated druntime and phobos too.
> 
> ./dmd  -c ~/arsd/terminal.d  -I~/d/wtf/druntime-master/src/
> -I~/d/wtf/phobos-master/
> # silence is good!
> me@arsd:~/d/wtf/dmd-master/src$

Hmm lemme try that again...

Yikes, I'm getting an ICE. :-(  Gah, looks like it's caused by -property, which is b0rken anyway. I'll take it out of my build file. Sorry for the false alarm!


> >I might just be able to get rid of my GUI browser dependence once and for all. :)
> 
> arguably it'd still be a gui, since it'd need to run in graphics mode and all! Just a *great* gui.

Right. :)


[...]
> >I do remember that feature in the BIOS, actually. I also remember it was horrifically slow. In fact, I reinvented my own text output system in assembly which was orders of magnitude faster.
> 
> Aye, all BIOS text output was brutally slow, I'm sure just about every DOS programmer did their own text output at one point or another!

I wrote my text routines with 6-pixel wide fonts instead of the normal 8-pixel font, just so I could cram more text onto the screen. :-P Needless to say, those were the days before I got a clue about typography.


> In text mode, you just write to segment 0xb800, and in graphics mode what I did was blit some little bitmaps over. Wrote my own bitmap font editor too.

0xb800 -- I remember that! Brings back the memories!


> Actually, I recently ported some of my old DOS drawing stuff to D, called image_basicdrawing.d. Does bresenham's line algorithm, ellipses, and bitmapped text.
> 
> I haven't put it to github yet though because I'm pretty sure I copy/pasted half that code back in the day and thus aren't sure about the copyright status!

Heh. I was on the other extreme... I reinvented everything from the square wheel to the triangular peg in the round hole. It was free of copyright issues, it's true. But it also mostly sucked. :-P


> >The first thing I'd do if I were to write a terminal spec is to get rid of the stupid dependence on ESC as the terminal control escape code.
> 
> god yes, especially on input. This is another thing (omg back to the roots of this hijack!) that Windows just does so much better.
> 
> Raw console input on Windows is delivered as INPUT_RECORD structs:
> 
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms683499%28v=vs.85%29.aspx
> 
> which is nice and structured. Extensible, unambigious, and a lot less hideous than the mess of input sequences you can get on linux.

Yeah... unfortunately the Unix obsession over everything being a byte stream is coming back to byte us. ;-)


> I guess it is less efficient over ssh, but it is so much simpler.

ssh -C. :)

How would you intermix it with character data, though? That's the problem with the Unix design. The control stream and the data stream is intermixed, which is the source of much of the headaches in terminal handling.


> Though, an easy fix to the unix thing: make your esc key send it twice. So ^[^[ == user hit esc, similarly to how "\\" is `\`. At least then it won't be as messy. Sending it twice might even be more backward compatible since a lot of unix programs either specifically watch for the second esc, or at least ignore the second one already since that's a fairly common manual workaround for the crappy design.

Hmm. I've gotta try that sometime. Does XKB support mappings like that? Or that is to say, I'm pretty sure it does but I've no idea how to configure that.


> If I was doing it from scratch, I'd probably say plain input is one byte, escape is either ^[ with ^[^[ the literal esc, or an invalid utf-8 byte like you said, though that might reduce error detection, and anything else is a struct: <ESC>size_of_struct type_of_event event_data....\n (or something).

But how would you intersperse structs in the middle of an input stream?

I suppose one way is to delimit it with invalid UTF-8 bytes like:

	0xFC <binary data> 0xFD

but then you have the problem of spewing random garbage to the screen if somehow the 0xFC got lost in transit. Again, it's caused by the Unix obsession of shoehorning everything into a byte stream. :-/


> The data could be binary or ascii, whatever, but this way you could skip it by only knowing the size (unlike the termcap mess on linux), it could embed arbitrary data in there, and is unambiguous.
> 
> Another thing that might be nice is to make sure it is all invalid utf bytes, but encoding data that way would get long. But then you could ignore it even if you missed the size - would be nice to recover a broken stream.

Right. The best solution is to admit that the control stream and the data stream are two different things, and use *two* streams for them. But then you may have trouble with synchronizing the two should there be network lag or packet reordering in between. Bah. Some days you just can't win.


> I'd do output similarly too. Escape sequences on output aren't nearly as nasty as on input - you probably don't output an esc character most the time - but still they should be structured enough so you can easily ignore unknown ones and be a little more binary safe.

Yeah no kidding. Nothing like `cat binary.file` turning your terminal settings into mush just because it happens to contain the wrong byte sequences. :-/

But on second thoughts, aren't terminals over raw, unreliable connections passé these days? As long as you have TCP, you should be good to go. The stream API for terminals should automatically escape *all* data, and have a separate set of APIs for sending control sequences. That way the terminal library layer ensures data is always correctly encoded. Writing raw data to a terminal is a dangerous operation anyway.


> Then you output a png image in that same set too!
> 
> 
> >rather than being constantly interrupted by dings and beeps and popups,
> 
> i love beeps lol
> 
> modprobe pcspkr

Heh. I'm the opposite. I hate beeps so much that I specifically configured my kernel to *not* have the pcspkr module. :-P


> >I never leave the title as 'rxvt'; I wrote a little program that writes the escape sequence to change the window title to the command-line args,
> 
> I did one of those too (a shell script too lol) but I do it spacially or transiently anyway - my rxvts either live long enough that I get to know them by position on the taskbar, or they are gone so quickly that it doesn't matter.
> 
> Another hassle is screen sometimes doesn't propagate that correctly which is annoying too...

Yeah, that *is* annoying. But that's more annoying is programs that randomly change the terminal title just 'cos they can. Thankfully, ratpoison lets me hardcode a manually-specified name onto windows, which causes the window's title string to be ignored. This way I can turn off intrusive title changes without the offending program even realizing it. :-P


> >Yeah I should stop talking about ratpoison replacements, and actually go write one. In D. With ranges. :-P
> 
> lol ranges

Well, ranges are one of D's big selling points, aren't they? :-P I mean after all, a WM is basically a program that processes a *range* of X11 events, outputs a *range* of X11 requests, manages a *range* of windows, etc...


T

-- 
Claiming that your operating system is the best in the world because more people use it is like saying McDonalds makes the best food in the world. -- Carl B. Constantine

On Tuesday, 17 September 2013 at 01:59:42 UTC, H. S. Teoh wrote:
> No kidding! Never knew that. I guess that just shows how b0rken (or antiquated) X11 font handling is.

indeed.

> 0xb800 -- I remember that! Brings back the memories!

Oh yeah. This is half the fun of my minimal-d (http://arsdnet.net/dcode/minimal.zip) toy that runs on bare metal (after booting with grub) - I can do some of that stuff again!

> Heh. I was on the other extreme... I reinvented everything from the square wheel to the triangular peg in the round hole.

Oh, I've done my share of that too, but my lines were so slow and Bresenham's algorithm was so fast, so I had to make the switch!

> How would you intermix it with character data, though?

If you have a reliable connection it isn't too bad. You can either define anything outside a struct to be character info or you can have an INPUT_TYPE_CHAR struct that showsit.

> That's the problem with the Unix design. The control stream and the data stream is intermixed, which is the source of much of the headaches in terminal handling.

Yup. I've thought before about doing up to five standard streams:

1) system control in, the event stream
2) user control in, a character stream
3) standard file in, a plain file. might be user control or might be another file
4) standard file out, might be the terminal or might be a file
5) interactive output, the terminal.


The #3 and #4 are different from unix stdin/out because they aren't necessarily the terminal. Suppose you want to edit a temporary file. You can'd do

echo "initial data" | vi

since that would be considered user input and be interpreted by vi as a command. So what you end up doing is something like this

echo "initial data" > /tmp/filexxx
vi /tmp/filexxx

And ditto on output, you'd tell vi to write to the tmpfile since redirecting stdout would screw up the user interactivity.

So the other files let you just set up pipes easily without necessarily hijacking the interactivity.


But, overall, I think unix does a pretty ok in this department - the system is simple, maybe too simple, but it gets the job done.

> Hmm. I've gotta try that sometime. Does XKB support mappings like that?

I don't know.

> I suppose one way is to delimit it with invalid UTF-8 bytes like:

yea.

> then you have the problem of spewing random garbage to the screen if somehow the 0xFC got lost in transit.

Right... but the connections are reliable enough that we can probably get away with just leaving that to the other layer (tcp or whatever).

> But on second thoughts, aren't terminals over raw, unreliable
> connections passé these days? As long as you have TCP, you should be good to go.

exactly

> Thankfully,ratpoison lets me hardcode a manually-specified name onto windows, which causes the window's title string to be ignored.

cool. Maybe I'll put that in my terminal emulator too...

> Well, ranges are one of D's big selling points, aren't they?

tbh I'm kinda meh on them. When they're great, they're great, but otherwise eh, no need to force them in when it isn't necessary.




BTW I did a lot of snippage here since I generally agree, but the big fun is I just spent the last half hour playing with the idea of doing my own terminal emulator again.

And you know, that might not be so hard. In just this short time, I got it started: in about 100 lines with simpledisplay.d and eventloop.d as helper libraries, I have it running a basic shell. The hard part is still coming: all the escape sequence nonsense, but that's kinda additive, I can just do each one as I come to them, making it more or less xterm compatible but just enough for the programs I use.... then start doing extensions!

Most the work is actually done by forkpty() apparently. It even handles echo automatically and I think it does line buffering too, I'll know more as I play with it. And of course, simpledisplay.d already does a lot of messy Xlib stuff and input events so this might not be that hard at all.

...until I get to the issue of utf8 font output lol.

On 2013-09-17 01:35, Justin Whear wrote:

> Do you know about C-x C-e?  If EDITOR is set to "vi" it should open the
> current command in vi as a temp file, allow you to edit, and when you
> write and quit it'll execute it.  Not sure if this is Bash only or
> universal.

OMG, it works with TextMate on Mac OS X. That is so cool :)

-- 
/Jacob Carlborg

On Mon, 2013-09-16 at 11:24 -0700, Walter Bright wrote:
> On 9/16/2013 8:02 AM, Jacob Carlborg wrote:
> > On 2013-09-16 16:28, H. S. Teoh wrote:
> >
> >> Which reminds me... it's probably time to make backups of $HOME again...
> >
> > Just push them to internet and someone will make the backups for you :)
> 
> Since the taxpayers already pay for an NSA backup of all our files, I think they should kindly provide a restore service!

Dilbert made use of this, found himself being taken to prison…

http://dilbert.com/2013-09-06/

… but read on for the denouement.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder