February 22, 2012
On Wed, Feb 22, 2012 at 01:21:41AM +0100, Adam D. Ruppe wrote:
> On Wednesday, 22 February 2012 at 00:03:35 UTC, H. S. Teoh wrote:
> >It lets me fire up my (text-based) mail client
> 
> mutt????

Yep!


> I switched to mutt from the terrible webmail in... 2007 I think. Rarely look back (only when I need to view images when on a separate computer).

Webmail gives me acne. For a while at my job before I figured out how to download work email onto my Linux development box, I had to use webmail. No threading, poor folder support, flaky search box, default HTML formatting (ugh!), it's like Windows 3.0 reincarnated. Eww.


> I handle 200-300 emails a day. I don't think I could handle it if not for how awesome mutt is.

Yeah, I saw several people remarking about how unmanageably huge the Exceptions thread is, but mutt handles it just fine. In fact, without mutt, I would've lost track of where the discussion was going a long time ago. (Although, it *is* starting to get to the point where the threading lines are going past the right edge of the screen...)

Come to think of it, perhaps that's why people started rehashing the same arguments over and over after a while, 'cos without proper threading support in your mail client, it's just impossible to keep track of who is replying to what, much less keep all the different conversations straight.

Years ago I used to be subscribed to a truckload of opensource mailing lists. On top of that, if I turned off spamassassin, I'd get about 200 spams a *day*. (My email address is too public, unfortunately.) Only mutt could handle that sort of mail load. I used to use pine, but it had no threading, which especially sucked for dealing with mailing lists: there was no way to delete-entire-thread without manually pressing D 300 times. IIRC it was mailing lists that convinced me to switch to mutt. Never looked back since.


> >music is finished, run mplayer to start new music, etc..)
> 
> mplayer rox. I also use a play script that runs sox (or timidity) for
> simple files.
> 
> gui music sux.

Yeah, it's just audio, why does it need a GUI interface, right? :) If it was video that'd be a different story.


[...]
> Aaaand I can run other screens inside!

Nice.


[...]
> Nested screens is pretty amazing. And that automatic
> session means I can open and close it at will, picking
> up exactly where I left off every time.

Nice, I should set that up sometime. I have screen running on a persistent session, but if I need to reconnect, I have to start over. It'd be cooler if it was *always* persistent unless the machine itself went down. Cool.


T

-- 
"Hi." "'Lo."
February 22, 2012
"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message news:mailman.830.1329870386.20196.digitalmars-d@puremagic.com...
> On Tue, Feb 21, 2012 at 06:01:37PM -0500, Nick Sabalausky wrote: [...]
>> Hmm, if that's like Total Commander on Windows, then I don't think I would like it. I do *love* Total Commander's multi-file renaming, but that feature is really the only reason I keep it around.
>>
>> Heh, as bad as this might sound, I think what I basically want is more or less Windows Explorer on linux ;)  (Including the customizations I've installed, like "DOS Prompt Here" and Tortoise*) And yea, Explorer works under wine, but it's kinda like running a GTK app in Windows - but worse since Windows GTK apps at least *know* what OS they're really running on.
>
> Maybe if you write one in D... ;-) Perhaps *that's* the killer D app that we've been waiting for, that will take the world by a storm. :P
>

I've seriously been wanting to, but it's one of many things I haven't been able to get around to yet.

I suspect, though, it might not end up so popular. Linux people like the command line. Although it might help further popularize Linux among WinXP fans...

But it's looking like Vlad's D forums might be on their way to being D's killer app anyway ;)

>
> [...]
>> > Keyboard/mouse switching is much better when it's a laptop with that "nipple" thing in the middle of the keyboard. In fact, that's the only
> [...]
>> I like to call it the clit mouse. It beats the shit out of trackpads (I
>> hate
>> those things with a passion), but I still find them a pain compared to
>> mice
>> and my trusty Logitech trackball. So I'm the opposite of you there: I
>> actually find it much *easier* to switch between keyboard and trackball
>> than
>> keyboard and "clit mouse" despite the increased distance. Maybe I'm just
>> weird.
>
> Are you trying to out-weird me? ;-)
>

Heh heh. That's puts me in mind of one of my favorite songs:

"[...]
The so-called weirdos in this country
Stand as completely freaked out by the normal man
As the normal man is completely freaked out
By the weird masses reaction to him

Which came first, you may ask
Chicken or egg, you may ask
Well, the chicken of course
It's time to break this weird-ass chain

The weird masses don't want to be normalized
Weirdos want to be abnormal
The freaks can't be formally normalized
Nor can we normally formalized
What we want is complete weirdification

Basically, we don't want weirdness from the normal man
We don't want to be freaked out by the normal man
We want to out freak the normal man
[...]
Because you are defending our weird women
From the freaky-ass thoughts of the bug-eyed
Bow-legged normal man"
 - Butthole Surfers: Weird Revolution

Heh :)

>
> OTOH, ftp.apple.asimov (together with an Apple II emulator) is a wonderful resource for those moments of nostalgia, when you're just feeling that urge to go boot up with a single beep and see that beautiful "]?" prompt staring at you, just like it used to decades ago. And then you 'call -151' and geek out on coding some assembly routines by typing in opcodes, etc..
>

Yea, I had an Apple II emulator (fantastic!) and some disk images, but I think I may have lost them all last time I had a HDD die. Gotta recollect that stuff...

>
>> I'm actually a huge Apple hater ever since I got fed up with my 10.2 eMac and the whole "Return of Jobs" world and product lines in general. But I *always* consider Woz's Apple II line to be the big, giant, glaring exception in Apple's portfolio.
> [...]
>
> Ah, good ole Wozniak. Wasn't he the one who practically single-handedly coded up the entire Apple II ROM? Or am I just mixing up urban legend with reality? :)
>

My understanding is that he designed the whole damn machine, period. And I have a tendency to believe it, because those older systems really *are* simple enough that it's totally possible for one person to understand every byte, every clock cycle, every chip and every wire. Hell, that's a big part of what makes those machines such a dream to work with anyway. And also what made them cheap enough for average consumers - *especially* the Atari VCS/2600 - That's just an absolutely beautiful design in it's minimalism (had to be, to be useful and only ~$200). Ever coded for it? It makes even the Apple II seem enormously complex and powerful. It's sooo fun.


February 22, 2012
On Tue, Feb 21, 2012 at 07:27:41PM -0500, Nick Sabalausky wrote:
> "H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message news:mailman.826.1329869015.20196.digitalmars-d@puremagic.com...
[...]
> > fg/bg is the best thing on earth since sliced bread. Well, to me. :)
> >
> > It lets me fire up my (text-based) mail client, read mail halfway, find someone mentioning an obscure library function, press ctrl-Z to suspend to mail client, `man obscure_function` to find out on earth they're talking about, then fg to continue reading mail.
> >
> 
> Yea, see I think the reason I almost never use it is because I'm still not used to having it available. "When all you have is a hammer..." So I instinctually just fire up another window, another connection, or another whatever, whenever I need to multitask.

It goes the other way too. When I use my wife's Windows laptop, I keep trying to ctrl-Z to background what I was doing, and I keep wondering, how do I get the list of backgrounded tasks so I can get back to that other thing I was trying to do?? :P  Scarily enough, sometimes ctrl-Z actually works... 'cos I'm usually on putty when using Windows. :P


[...]
> Not sure if I'll actually end up kicking the habit of avoiding it though.  I've spent years on systems (including Windows) with multiple desktops available in the taskbar, and I always ended up just using one of the desktops. I always liked the idea of multiple desktops, but using more than one just meant spending more mental effort on organization and "What the hell desktop did I leave that window on??". heh :)

Yeah I tried multiple desktops for a while, but after a while it was just too hard for my little brain to keep track of where things are. Some WMs try to help by displaying a little desktop map in the corner, but it doesn't help when you have large windows obscuring small ones completely.

Eventually I gave up and went the other extreme: ratpoison.  No mouse, no window title bars, in fact no overlapping windows (except modal popups), everything is maximized to full-screen, and you switch between them with keystrokes (which if you keep them <10 in number, you can address just by doing ctrl-T [0-9]). Remembering a number is easier than remembering a location, and at least you can see a simple numbered list when you ask the WM for it, not some jigsaw puzzle that you've to solve on the spot to find that window you minimized who knows on which other desktop.

But I wouldn't recommend ratpoison to anyone except rabid hardcore CLI geeks like myself. Most people cringe when they see my "desktop" environment. "*That's* your OS?!" they would exclaim. It's just a wall of text. And then I would flip between a few windows, do some fg's and bg's, and they'd be completely lost. "What on earth did you just do? What's all those letters and symbols mean?" My wife sometimes asks me, "Do you really understand all this stuff?" when the screen is busy scrolling past during a large compile job. "How do you read all that stuff so quickly anyway?!" :-)


> > Yeah. And worse yet, I've actually encountered GUI Linux apps that expect input from stdin. I'm not kidding. As they say, fact is stranger than fiction.
> >
> 
> Eww. That's just...wow.

At least it's no worse than this one time, I had a browser plugin go *really* wrong, and it launches mplayer which somehow believes that it's being launched from a terminal instead of X11, and then it tries to read from the *browser's* stdin, causing the browser to get suspended by SIGTTOU, but when I try to fg the browser, it auto-backgrounds itself 'cos it wasn't designed to read from stdin. Or at least, I *think* that's what happens.  Who knows. Something in there somewhere has gone completely wrong, so now *both* the browser *and* the plugin that launched mplayer are stuck in this limbo of trying to read stdin but it's not actually possible to type anything into it. :P


> >> The whole Unix philosophy is orthogonality, one tool to do one task well, no duplicated functionality for slightly-different use cases. The whole "sudo" vs "gtksudo/kdesudo" thing seems to be some sort of big ugly hack.
> >
> > It's to prevent people from doing foolish things like logging in as root and doing everyday tasks as root, just because one or two commands *might* require root privileges. It's convenient, it's like Windows and DOS where you can do pretty much anything without this troublesome protection thing.
> 
> Oh, no, that's not what I meant. I understand the need for sudo, and I'm totally in favor of it. What bugs me is why we *also* have "gtksudo/kdesudo". Ie:
[...]

Ahhh, I see. Mea culpa. :)

The reason is because that monstrosity known as X11 decided to trump the original Unix design, and implement a security protocol of its own. I won't get into the gory details here, but basically the usual su/sudo does give you root access, and the GUI app is actually running as root, but it needs to connect to X11 via a socket, and the X server has no way of knowing if the process it's talking to over the socket is running as root or not. So it asks for authentication tokens which root doesn't have, 'cos they're sitting in the original user's $HOME somewhere, but the GUI app doesn't know this, so it tries to look in root's $HOME and finds nothing.

That's where gtksudo (or whatever it is they call that monstrosity) comes in: it not only gives you root access, but also sets up some environment vars in root's environment so that GUI apps launched from root will actually be able to find the original user's X11 authentication tokens (and possibly some KDE/GTK-specific stuff as well).

Yeah I know. Wayyy over a newbie's head, for no good reason at all.


T

-- 
Give me some fresh salted fish, please.
February 22, 2012
On Tue, Feb 21, 2012 at 07:45:36PM -0500, Nick Sabalausky wrote: [...]
> Windows's cmd.exe always inserts a newline right before a command prompt. So you get the best of both worlds. Only issue is you end up with excess newlines. For example, you get:
> 
> C:\>echo Hello > filea.txt
> 
> C:\>echo Hello > fileb.txt
> 
> C:\>
[...]
> Come to think of it, bash should be able to do the same thing if you add a newline to the beginning of $PS1...
> 
> Ha! It does work! Boy is that funny, it makes bash look like windows :) That's just weird.

LOL... yeah that *is* weird.


> But, of course, it does mean a lot of extra blank lines. Which is ugly if you're doing a lot of no-output commands. But then, it's also much easier to read when there's a lot of heavy-output commands. It's a tradeoff :/
[...]

I was going to suggest writing a terminal wrapper to postprocess bash's output to compress unnecessary blank lines, but then I realized it won't work, 'cos bash does try to outsmart the outdated terminal concept by querying the kernel about what kind of stdout it's talking to. If it decides that the wrapper is a "dumb terminal", then you'll get a crippled shell with no meta keys, no history, no colors, no nothing except pure stream output. Which is a lot worse.

And even if you manage to coax bash to work properly, this would probably also break most text-mode programs that try to do anything more than just write to stdout as a stream (like anything using ncurses). So the result would be totally unusable. :-(

Oh well.


T

-- 
If creativity is stifled by rigid discipline, then it is not true creativity.
February 22, 2012
On Wed, Feb 22, 2012 at 01:33:56AM +0100, Adam D. Ruppe wrote:
> Thinking about globbing, I think rm * is a mistake anyway...
> 
> The way I'd do programs is something like this:
> 
> echo input > program_name options....
> 
> So, you wouldn't rm *. You'd ls | rm.
> 
> You'd implement rm like this:
> void main() {
>      foreach(file; stdin.byLine)
>          std.file.remove(file);
> }

Hmm. Let's implement shell utilities in D! (Pointless, yeah, but a fun exercise to see how much cleaner D code can be -- if you've ever looked at that creeping horror that is the source code for 'less'.)


[...]
> This way, options and things to operate on
> are nicely separated, and you can process
> the input with more filters easily.
> 
> glob * | grep 'poo' | rm

Interesting idea. This calls for ... a shell written in D. :-)


[...]
> Windows Powershell actually kinda works this way,
> from what I know of it. You can do
> 
> ps | kill
> 
> and it works.

Nice.


[...]
> I almost *almost* want to write my own custom userland.

Only? Heh... when I was young and foolish, I wanted to trump Linus and write my own kernel.

But seriously, I *do* contemplate from time to time about writing my own shell. I have lots of beefs against the way current shells are implemented, globbing being one of them, or more generally, excessive implicit interpolation, that turns something simple like \00 into nonsense like \\\\0000.

My concept of shell is to make it a very thin (but scriptable) layer over actual syscalls, so you could do something like:

	% open data.txt
	&3: /home/data.txt		# data.txt bound to &3
	% send &3 | grep abc		# pipe data.txt to grep
	abcdef				# output from grep
	% echo @@			# @@ stands for "last output"
	abcdef
	% write &3 @@			# write "abcdef" to data.txt
	% close &3			# detach data.txt

But I haven't actually sat down to think this through, so I don't know if how practical/usable this will turn out to be. Maybe this will be my next D project. :P


> But, while I can complain all day about what we have...
> meh it works well enough that I'm in no rush to spend
> a lot of time replacing it.

True.


T

-- 
"The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts." -- Bertrand Russell. "How come he didn't put 'I think' at the end of it?" -- Anonymous
February 22, 2012
On Wednesday, 22 February 2012 at 02:03:58 UTC, H. S. Teoh wrote:
> Hmm. Let's implement shell utilities in D! (Pointless, yeah, but a fun exercise to see how much cleaner D code can be -- if you've

I'm sooo tempted again.

Though, I don't really like shell utilities.... I'd want many
of them to be accessible through api, and at that point, might
as well just do them all as built ins.

I guess if there's another file available, we can call it
instead to allow easy replacement, but I just think making
the shell there as a library is a really nice thing.

class ShellOperations { /* methods here */ }
then use compile time reflection to build your map for the
command line processing....

Our D shell could be just one program.


though tbh if I was doing a shell, I'd kinda want to do
a terminal replacement too. But, I don't see myself leaving
xterm and rxvt. Nor putty.

idk, should probably limit the scope a bit just to make it
realistic to finish. Use gnu readline too and piggyback on
that pretty nice function for history, editing, completion,
etc.


Actually that makes it fairly doable as a weekend project.

> Only? Heh... when I was young and foolish, I wanted to trump Linus and write my own kernel.

I've tried it before.... but it is terribly boring.

As cool as it is to say "every line of code on that box is
mine and mine alone", that's all it is good for imo: bragging.

The interesting stuff is all user territory.

> My concept of shell is to make it a very thin (but scriptable) layer over actual syscalls, so you could do something like:

Eeeeeeh.... at that point, you might as well just write
your commands in C (or D).

I actually like bash a lot... but only for 1-3 line things.
Bigger than that, and screw it, I'd rather just write C/D.
bash is a huge pain to get anything done for > 3 lines...

But for those 1-3 line things, it is really nice. And, since
it is a command line shell, that's exactly what it should be
optimizing!
February 22, 2012
On 22 February 2012 13:06, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
> On Wed, Feb 22, 2012 at 12:39:01AM +0100, Adam D. Ruppe wrote: [...]
>> Yeah, though I've only seen it suggested for daemon like programs... I think you're the first person who I've seen suggest it for gui apps too.
>>
>> Not a bad idea.
>
> Perhaps I'm just dreaming, but I *think* I've seen one GUI app that actually does that. But I could be wrong.
>
>
> T

GVim does it, its amazing, since I normally start it from the terminal and chronically forget to use '&'. The one downside of this is when you /want/ the blocking behaviour (git editor for example), gvim gets around this by providing a '-f' flag that tells it not to fork.

I wish all GUI programs provided that kind of feature set, but I concede that GVim is made /for/ programmers and launching from the terminal is a common use case, as is wanting to use it as a drop in replacement for vim, so here we are.

--
James Miller
February 22, 2012
On Wed, Feb 22, 2012 at 03:44:33AM +0100, Adam D. Ruppe wrote:
> On Wednesday, 22 February 2012 at 02:03:58 UTC, H. S. Teoh wrote:
> >Hmm. Let's implement shell utilities in D! (Pointless, yeah, but a fun exercise to see how much cleaner D code can be -- if you've
> 
> I'm sooo tempted again.
> 
> Though, I don't really like shell utilities.... I'd want many of them to be accessible through api, and at that point, might as well just do them all as built ins.
> 
> I guess if there's another file available, we can call it instead to allow easy replacement, but I just think making the shell there as a library is a really nice thing.

Totally!! Instead of 500 standalone shell utils, each with the same old boilerplate command-line parsing, each of which requires fork() and exec() to use, why not make their functionality directly available as a library?

It's clear that the trend of computing is toward automation anyway. In the long-term, it isn't so much about how l337 your CLI skills are in stringing 20 different commands together in one line, it's about how the commonly-used functionality in these 20 commands can be reused by *programs* that call common library functions. Shell-scripting is only a temporary solution; all those fork/exec calls do add up.

This reminds me of a funny incident at my first job, where there was a shell script that a coworker was using to generate some reports. It worked fine up till that point, since it had only been used for relatively small datasets. That day, someone tried to generate a rather large report, and it was taking forever. In fact, it took >48 hours to complete. When the prospect arose that we might need to generate similar reports again, they approached me to ask if I could do something about the obvious performance problem of this script.

Turns out the script was really simple, but had to do some amount of calculations, which it did using code along these lines:

	while [ ! -z "$still_more_data" ]; do
		$data=`cat $inputfile | sed -ne${linenum}p`
		$input=`grep $fieldname $data`
		$result=`expr $result + $input`
		...
	done

There were several *nested* loops like that. I didn't analyze it much further, but it must had been something like O(n^6) complexity or something insane like that, due to cat'ing the (same) input file umpteen times, grepping each line multiple times, saving results to temporary files and then grepping *those* files (multiple times), and spawning who knows how many subprocesses along the way.

I rewrote the miserable thing in Perl in a couple of hours, and the Perl script took 2 minutes to produce the report. :-P

So yeah. A shell utils library would definitely be a big plus.


> class ShellOperations { /* methods here */ }
> then use compile time reflection to build your map for the
> command line processing....
> 
> Our D shell could be just one program.

Yeah, a shell with many commands built-in is a good thing, IMHO. I had to rescue a remote server using only echo commands (one of the only commands built into bash). If rm, ls, and friends had been part of bash instead of needing a fork() and exec() followed by dynamic linking every single time I typed a command, things would have gone a *lot* smoother.


> though tbh if I was doing a shell, I'd kinda want to do
> a terminal replacement too. But, I don't see myself leaving
> xterm and rxvt. Nor putty.

If you were savvy (or crazy) enough, you could always try your hand at writing termcap/terminfo entries... :P


> idk, should probably limit the scope a bit just to make it realistic to finish. Use gnu readline too and piggyback on that pretty nice function for history, editing, completion, etc.

True. For a first stab at it, I wouldn't go crazy with trying to rewrite the terminal. Get some working code first, that's actually usable at the basic level, then we can get fancy. Nothing more discouraging than a grandiose uber-design of a utopian system that's sitting in the source tree with thousands of lines already written but nothing actually running, and nothing runnable for the foreseeable future.


> Actually that makes it fairly doable as a weekend project.

Go for it!


> >Only? Heh... when I was young and foolish, I wanted to trump Linus and write my own kernel.
> 
> I've tried it before.... but it is terribly boring.
> 
> As cool as it is to say "every line of code on that box is mine and mine alone", that's all it is good for imo: bragging.

I dunno, I've always loved low-level coding. I used to keep an eye on Hurd, because the prospect of moving most kernel functionality into userspace appealed to me very much. But nowadays I just don't have the time for highly time-consuming projects like that.


> The interesting stuff is all user territory.

Depends. Linux driver development is a constantly growing area, if you're into that sorta thing. You won't have fancy graphical sfx to show for it (unless you're into video driver development), but you'll have the great satisfaction of knowing that you made that particularly stubborn piece of hardware actually work nicely with Linux.


> >My concept of shell is to make it a very thin (but scriptable) layer over actual syscalls, so you could do something like:
> 
> Eeeeeeh.... at that point, you might as well just write
> your commands in C (or D).

Well, yes and no. The point was more to play around with syscalls interactively.

Of course, I also have other shell ideas on the other extreme of the spectrum, where it's sorta like interactive D, except with a filesystem navigation / file searching / file manipulation bent, rather than trying to write a compilable app. (Though it wouldn't hurt if scripting in such a shell actually was the same as writing an actual D program. :P)


> I actually like bash a lot... but only for 1-3 line things. Bigger than that, and screw it, I'd rather just write C/D. bash is a huge pain to get anything done for > 3 lines...

For that I use perl.


> But for those 1-3 line things, it is really nice. And, since it is a command line shell, that's exactly what it should be optimizing!

I can't say I'm too fond of bash syntax. I guess it does the job, and is relatively expressive, so it's OK. But I'm a programmer-head, so I tend to turn everything into a programming language. :P (Or Turing tarpits on bad days.)

On another note, in my first job we had a temp consultant one time, who had the uncanny ability to write insanely-long bash commands that Just Work(tm). It's like he thinks in bash, and these insanely elaborate commands just flow out of him. They are always on a single line, but can involve 10-15 different programs in a long chain.  They always work on first try, and work wonders every time. To this day we still don't know how he does it.


T

-- 
Why do conspiracy theories always come from the same people??
February 22, 2012
This is just a guess, since I've mostly used GUI access (VNC, Citrix and lately RDP).

I would say SSH use in Windows is quite limited, depending on what you want to do,
because historically most Windows developers lack the culture to separate application code
from UI, which leads to many applications to be available in GUI form only.

This has been changing in the last years since Microsoft introduced Powershell and due
to market pressure created headless versions of Windows. But even if Microsoft
would do everything the correct way, programmer culture takes years to change.

--
Paulo

"Nick Sabalausky"  wrote in message news:ji0fb2$2hbp$1@digitalmars.com...

"Adam D. Ruppe" <destructionator@gmail.com> wrote in message
news:epzlyfzibmpuoilawaqz@forum.dlang.org...
> On Tuesday, 21 February 2012 at 00:38:46 UTC, Andrei Alexandrescu wrote:
>> ssh into Windows and... well last time I did it it was like "welcome to Hell".
>
> Oh, certainly!

Does anyone suppose it would work better (or at all) to ssh into MSYS/MinGW?
Anyone tried?

Also I'm curious: what sort of problems were there ssh-ing into win?

February 22, 2012
On Wed, Feb 22, 2012 at 08:53:06AM +0100, Paulo Pinto wrote: [...]
> This has been changing in the last years since Microsoft introduced Powershell and due to market pressure created headless versions of Windows.

Wow. Headless Windows? Can it even be called Windows anymore? :)


T

-- 
IBM = I'll Buy Microsoft!