Questions about windows support

H. S. Teoh hsteoh at quickfur.ath.cx
Mon Feb 20 19:54:56 PST 2012


On Tue, Feb 21, 2012 at 04:00:17AM +0100, Adam D. Ruppe wrote:
> On Tuesday, 21 February 2012 at 02:05:16 UTC, H. S. Teoh wrote:
> >Same with Linux, I thought? Although I mainly just use vim for
> >programming, so maybe I'm unaware of the full situation.
> 
> Yup.
> 
> >Terminal escape sequences?! You should be using libcurses or
> >libncurses.  No wonder you had a bad experience. :)
> 
> They don't help that much, since they can't hide the underlying
> reality.
[...]
> Even old, fairly reliable programs have trouble with mouse. I do most
> my programming in vim, inside gnu screen, displayed in an xterm.
> 
> Sometimes, it works great. Sometimes, though, if I click too far to
> the side.... it sends some bizarre sequence that vim interprets as a
> drag then input.
> 
> The ugly escape sequences showed through to the end user (me)!

I've always been of the opinion that ALL control sequences should be
sent over a separate channel. Mixing controls with data (characters) is
a Bad Idea(tm). But alas, if you were to implement such a terminal,
pretty much *everything* would break, since everyone assumes the
terminal is just a single stream of mixed controls + data.


[...]
> Oh yeah, another one. Ever try to make an app in ncurses where you
> hold in a button? I believe it was shift+page up that I wanted, and
> its impossible because the terminal it is emulating didn't have a
> sequence for shift pressed, shift released, nor shift+page up.
> 
> You could do that if you were talking to the hardware... but linux
> emulates some ancient pieces of trash, so you're left out.

Is that because you're trying to do this through gnu screen? I use
screen all the time too, and I've discovered that it does really strange
things with terminal settings. When I use ssh directly, these problems
go away. Perhaps it's a bug in screen.


[...]
> Oh oh, one more. Ever try to run a colored app in a different color
> terminal?

I'm not a fan of using colored terminals. It's trying to patch new
functionality over an incompatible interface. You're bound to have
problems.


> vi with syntax highlighting fails easily. In vim, you can do
> :set bg=light. My vimrc has an environment variable I set (ELVISBG)
> for my various things.
> 
> But... run it in screen. Start it in a white xterm. Detach and
> reattach to a black putty.
> 
> The contrast is all wrong.
> 
> There's no way for an app to query the colors in a unix terminal!

Oh? I thought ncurses does.


> Some ncurses apps just redraw the whole thing. Some use environment
> variables or something.

But you're right that most ncurses apps just assume that once they start
running, the colors will stay put. Assumption fails as soon as screen
comes into the picture.

Most *good* ncurses programs will repaint the screen on a keystroke,
like ^L. But yeah, that's a workaround, not a solution.


[...]
> Speaking of out of whack, ever resize a terminal connected to a remote
> session and see it not work? You're typing a long command, and it
> suddenly wraps back well before the edge and overwrites your old
> stuff.

I think you're seeing bugs in screen. I can resize my ssh terminals no
problem, it manages to communicate that fact to the remote end, which
sends a SIGWINCH to the app, which then resizes itself. This works in
putty from Windows too.

But once screen sits in the middle, all bets are off.


[...]
> Here's another one: have someone set a prompt with a wrong escape
> sequence. bash will mess up the length and will draw over your other
> stuff as you backspace.

Heh, never seen that before. I usually just turn off all fancy settings
after installing a new system, and just stick with a bare-bones prompt.


[...]
> I've been using linux every day for about seven years now. I can go on
> all day!

Only seven years? ;-) I've been at it for several years longer.


[...]
> The windows one isn't perfect, not by any means, but it has
> a nice separation of control, input, and output.
> 
> The Windows console api separates these things. You have an output
> buffer and an input event loop, with key and mouse events. You can set
> attributes on the cells (very much like the hardware again :) ) and
> get updates and query the system separately from the I/O channel.

Oh? This must be new. The last time I actually programmed anything on
Windows was... oh wait, it was on DOS. :P  The creeping horror that was
Windows 95 was one of the things that prompted me to switch to Linux for
good. But I don't remember console I/O being so nice. They must've
improved it since I last saw it.


> Much better design. If it did selecting by lines by itself and had
> nicer resizing, it'd be a real winner.

The fundamental problem with the Unix concept of terminal is that it
wants to treat EVERYTHING as a stream of bytes. Which is a powerful
abstraction, granted, but when it fails, like when escape sequences get
out of sync, it fails in horrible ways. I've always argued that control
and data needs a clean separation.


> >But I agree with you though, that libc incompatibilities are really
> >really REALLY annoying.
> 
> Even worse is linux's binary incompatibilities.

But that can't be helped when you have such proliferation of distros,
OS versions, library versions, etc.. I almost never download binaries,
only source.


[...]
> Yes and no. bash (and the kernel) is good about it now,
> but it is an effect of the unix design of the shell
> doing the expansion.
> 
> rm *
> 
> could have sent argv == ["rm", "*"], and your app
> simply done foreach(a; glob(argv[1..$])) { delete(a); }
> or whatever.
> 
> But, unix decided to do this in the shell. Which isn't
> all bad, it has some nice effects.

My favorite effect is this:

	mv filename.{oldext,newext}

which only makes sense if the shell expands it.

OTOH, I quite miss the good ole DOS days with Norton Commander, where
you can type:

	rename *.oldext *.newext

and it would do the right thing.


> But, run that in a folder with 20,000 items, and you send 20,000
> strings in argv...

I remember hitting an upper limit on that once, but I don't know if I
remembered correctly.


> Another side effect of this is
> 
> rename *.html *.htm
> 
> doesn't just work, since it is all expanded there. You have
> to make sure the wildcards are all at the tail of the
> command, so you have
> 
> rename .htm .html *.htm
> 
> instead. Not bad, and an easy rule to get used to, but kinda annoying
> at times.

I find it *very* annoying. But still, with all its warts, I find myself
much more productive at the commandline than at a GUI.


> >Besides, what *were* you trying to do with such a long command-line
> >anyway? :-)
> 
> 
> Once company I worked for had an old FreeBSD system that dumped tens
> of thousands of files in a few locations...  which tended to fill up
> the disk.

Ah. Ouch.


> They had a cronjob to delete stuff every so often, but it grew big
> enough that the cron failed because there was too much to delete.

LOL...


> And then the disk filled up and it was piles of fun. You'd be amazed
> at how many unix apps refuse to run if they can't write to /tmp!

Ugh. Don't remind me. At work I use ctags a lot so that I can use vim's
tag function (super useful for navigating large source trees!). Then
recently, some new code was introduced that produced hundreds of
thousands of symbols... and ctags would soak up all RAM, thrash on I/O,
near-freezing the computer, then die at the end when sort runs out of
space in /tmp.

It's both funny and sad at the same time.


> >Most distros do distribute prebuilt binaries, but if your app
> >isn't part of the distribution, things get tough.
> 
> Aye, or if the version you need isn't in there. centos, I'm looking at
> you!

That's why I love debian backports. :)


> >But then again, I *did* also have to deal with having to repair a
> >remote Linux server whose dynamic linker broke
> 
> I've had that one too.... I had the luxury of being able to put in a
> cd though. Mount the drive and copy that stuff back to it.
[...]

Provided 'mount' and 'cp' are statically linked, otherwise you're still
screwed.  Of course, if you could boot from CD, then you're OK.

I didn't have the luxury: it was a remote server (hosted at a very
remote location).


T

-- 
Don't throw out the baby with the bathwater. Use your hands...


More information about the Digitalmars-d mailing list