February 22, 2012Re: Questions about windows support
Posted in reply to Adam D. Ruppe
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, 2012Re: Questions about windows support
On Tue, Feb 21, 2012 at 07:27:41PM -0500, Nick Sabalausky wrote: > "H. S. Teoh" <email@example.com> wrote in message > news:firstname.lastname@example.org... [...] > > 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, 2012Re: Questions about windows support
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 23, 2012Re: Questions about windows support
Posted in reply to Adam D. Ruppe
On Thu, Feb 23, 2012 at 03:56:49AM +0100, Adam D. Ruppe wrote: > I started the dshell just to waste a little time: > > http://arsdnet.net/dcode/dshell.d > > dmd dshell.d -L-lreadline -L-lncurses > > It doesn't do much here, but there's a few things I think > are cool: > > 1) D reflection rox. You can write D functions with simple > arguments and it works basically. I want to detect bitfield > enums to automatically do -flags too. Nice!!! So you can write the same code for both the "shell library" and the actual shell itself. > 2) Your functions can return whatever, and it is wrapped in > a runtime polymorphic range. Cool, this is better than just plaintext stdin/stdout. :) > If you just want strings, you can do ProgramDataByLine(input). > > If you want something fancier, you can use originalProgramData!Type > to fetch out the original input range. Nice. > The syntax is so far just the basics... calling functions > and pipes. The echo command has a bug, it's not supposed to output 'echo' as part of its output. :) > but hey its kinda cool already. It's extremely cool. Definitely orders of magnitude better than writing the equivalent thing in C. Can you imagine the amount of code duplication & ugliness that you'd need in an equivalent C implementation? Without reflection, you'd either need hand-coded tables all over the place or insanely complex nested macros that nobody can understand. T -- GEEK = Gatherer of Extremely Enlightening Knowledge
February 24, 2012Re: Questions about windows support
Posted in reply to H. S. Teoh
On Thursday, 23 February 2012 at 19:10:03 UTC, H. S. Teoh wrote: > Nice!!! So you can write the same code for both the "shell > library" and the actual shell itself. Yeah. This is similar to the technique I used in my web.d thing, though web.d's is a lot more complex. (It also handles sub objects, argument name and default values, and some more.) I just find it super useful. > The echo command has a bug, it's not supposed to output 'echo' > as part of its output. :) Yeah, I messed up argv. Here's an updated version: http://arsdnet.net/dcode/dshell.d added basic formatting to the data interface, lazy printing (try "cat" and type in stdin) and bug fixes. I just might put it up on the github over the weekend. > It's extremely cool. Definitely orders of magnitude better than > writing the equivalent thing in C. Hell, this kind of thing is easier in D than in a lot of dynamic languages! imo anyway. eval is sometimes nice but having the type information available to do a smart wrapper is very nice.
February 27, 2012Re: Questions about windows support
On Sun, Feb 26, 2012 at 05:10:35PM -0500, Nick Sabalausky wrote: [...] > I've just thought of (ie, gotten bit by) another thing that would be > nice about having the commands do their own globbing: > > If the applications glob on their own insted of the shell, then for > safety they can choose to restrict the number of file args they take > to whatever makes sense for their own individual purpose. > > For example, suppose you want to delete everything inside a given > subdirectory (but keep the directory itself). So then you (mis)type: > > $rm somedir/ * -rf > > Note the subtle space before the "*". I just did that by mistake > earlier today, and the damage set me back a few hours (could have been > much, much worse, though). I don't think there's much, if anything, > that can realistically be done to protect against that right now. At > least without getting really hacky. If rm did its own globbing, it could warn the user before proceeding with a mass deletion involving *. (IIRC DOS's 'del' used to do this.) With the shell doing the expansion, there's no easy way to do this. > But, if rm was expected to do its own globbing instead of the shell > doing it, then rm could say: "Ok, it only makes sense for you to give > me one file/path at a time. Want more? Run me multiple times or use a > glob pattern (or hell, a regex pattern, or use a special explicit > 'accept multiple paths' mode, etc)." Then: > > $rm somedir/ * -rf > ERROR: rm only takes one path at a time > $rm somedir/* -rf # ok > $rm somedir/ -rf # ok > $rm * -rf # ok > > With the shell doing the expansion, that sort of thing isn't even > possible. I guess you could have a flag for when you explicitly want to specify multiple filenames: $ rm abc.d def.d ERROR: rm only takes one path at a time $ rm -m abc.d def.d # ok $ > Works with other stuff too: > > $cp a b c > ERROR: You gave me a source path and a destination path, but then you > gave me *another* path! What the hell you expect *me* to do with it? [...] But sometimes you want to copy multiple files to a destination dir. But I suppose you can always use a glob or specify an option to say "yes I really want to copy multiple files into a target dir". T -- It is impossible to make anything foolproof because fools are so ingenious. -- Sammy