View mode: basic / threaded / horizontal-split · Log in · Help
February 21, 2012
Re: Questions about windows support
"Bernard Helyer" <b.helyer@gmail.com> wrote in message 
news:iianhomhapvkfhidezbr@forum.dlang.org...
> >Nick replied to something about globbing
> Having programs doing the globbing sounds great until you run into someone 
> who doesn't play ball. *cough* every single digital mars utility *cough*. 
> I think Windows and unix both get it wrong, but unix gets it less wrong 
> (as it could theoretically be annoying, but in practice I just escape it 
> and move on, but working around a non-globbing program is just annoying).
>
> Wot I think should happen: the runtime (say libc) should handle globbing 
> of arguments, and it should be enabled by default. So if someone wants an 
> app that handles wildcards specially, they can do that, but for most apps 
> it'll just workT. I don't think this really meshes with the traditional 
> main signature of just passing the strings as arguments. Perhaps just a 
> non_globbed_args function or something.
>
> Buuuut things are pretty much set in stone at this point.

I dunno about that. The problem is that in the default "just work" case, the 
app still has no idea that the shell is sending it things that are 
*supposed* to be interpreted as filenames, so you still end up with that 
"touch -- --ha-ha-fuck-you" fiasco.

Also, libc/whatever has no way to know when a glob does or doesn't even make 
sence in the first place. What if you want to do something like: 
"fooapp --special-files=blah*.baz" The app knows how to handle that right, 
but if fooapp's authot forgot to disable the autoglob, the runtime will just 
fuck it up and remove the arg entirely (unless some jackwagon previously did 
"touch -- --special-files=blahblah.baz").

Or if the app allowed "fooapp --regex r/blah*blah/" which wasn't even 
*intended* to be a glob. In that case, too, the app itself would have *make 
sure* to remember to disable the default setting so it works right. It'd 
just be another thing for developers to watch out for and possibly screw up.

I think that globbing should be done explicity by the app, *but* for apps 
that don't play ball you should be able to *explicitly* do it at the command 
line. Example:

$someutil *.txt foo.html
ERROR: Can't find file '*.txt'
$glob *.txt
'hello.txt' 'Modern File Name.txt' 'another.txt'
$someutil `glob *.txt` foo.html
Processing hello.txt...done
Processing Modern File Name.txt...done
Processing another.txt...done
Processing foo.html...done

Erm...actually, that glob tool above would probably have to work more like 
this:

$glob *.txt
'hello.txt' 'Modern File Name.txt' 'another.txt'$someutil `glob *.txt`
Processing hello.txt...done
[etc...]

Which brings up another little nitpick: When bash displays a prompt, it 
should first check to see if the last char output was a newline. If not, it 
should...ADD ONE!
February 22, 2012
Re: Questions about windows support
On Tue, Feb 21, 2012 at 06:22:25PM -0500, Nick Sabalausky wrote:
[...]
> That hadn't occurred to me. Thanks. Normally, the only time I use
> fg/bg is if I try to cancel something with Ctrl-blah and it suspends
> the process instead of stopping it. So then I "fg [whatever num]" and
> either try a different key combo or let it finish.

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.

Or, I'm doing some heavy D coding (yeah!), run into some syntax I'm
unsure about, so ctrl-Z to suspend vim, pushd /tmp, vim test.d, write
some test code, ctrl-Z the second vim, run gdc/dmd to see if a
particular construct compiles and does what I think it does, if not, fg,
edit more code, ctrl-Z, recompile, whoopie, it works now, fg, :q! to
exit 2nd vim, now fg %1 to get back to 1st vim, continue heavy D coding.

And somewhere in the midst of all that, the background music gets too
loud, so ctrl-Z to suspend whatever I was doing, run alsamixer to adjust
volume, quit, fg to resume what I was doing. (Or do the same thing when
music is finished, run mplayer to start new music, etc..)

All this, within a single rxvt terminal. I don't even have to switch to
a different window or take my hands off the keyboard. On a good day, I
can have up to 4 or 5 backgrounded processes, mostly vim sessions with
heavy D coding, perhaps a mail client, a 2nd mail client in the middle
of a long reply, a pager viewing an open manpage, etc..

Yeah. I'm such an ubergeek. :P  I only actually need more than one
terminal when dealing with spammy programs, like long-running large
compile jobs, or mplayer (unless I silence it with `echo -n | mplayer
... >/dev/null 2>&1&` -- the echo is there otherwise mplayer insists on
reading stdin from the terminal, which when it's backgrounded causes it
to get suspended by SIGTTOU -- yet another gratuitous tty annoyance
inherited from the old days). Or when I lose my geekiness and actually
switch to a GUI browser window. :P


> But still, I'd venture to say that probably 99.9% of the times you
> launch a gui app from the command line, you don't want, or at least
> don't need, it to be blocking or spamming the console. It'd be nice if
> it could do like windows and detect "gui or cmdline" so it can
> automatically do the right thing without the user coddling it.
> Unfortunately I'm not sure that's possible since I don't think Linux
> binaries are flagged as "cmdline or gui" like in windows. It just
> either calls some GUI apis or it doesn't.

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.


> That reminds me of another thing (yea, I know I sounds like I'm just
> ranting on and on about Linux, but I *do* rather like it overall):
> What the hell is up with this "sudo" vs "gtksudo/kdesudo" shit? I
> understand that it's somehow necessary for the
> permissions/process-owner stuff to all be right, but why should *that*
> be necessary?

Because Unix was designed with multiple users in mind. It has to ensure
that users don't stomp all over each other.


> 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. Like install programs and stuff.  Until one day you
want to remove everything from the current directory but instead type
this as root:

	rm -rf . /*

(The space between . and / is a typo... that you will regret for the
rest of your life.)

In the old days, you'd just be restricted to a non-root user, so certain
programs won't run (they need root access to, e.g., access a certain
hardware). You have to `su - root`, type in root's password, run the
program, then exit from root. Very tedious. Sudo lets you use your
*user* password and runs exactly a single command -- the one command
that actually *needs* root access. Everything else stays in non-root
space, so even if you screw up and destroy your entire home directory,
the system itself is still intact and you can still recover.

Whereas the above command, running as root, will likely cripple your
system in the few seconds before you notice something is wrong, and
quite possibly ruin your entire day (and the next 2 days) in the
following few seconds before you react and hit ctrl-C. Depending on what
order rm tries to delete stuff, by the time you stop it there may not be
anything left in /bin or /usr/bin, and then you'll have to be macho and
use echo commands to recreate binary files. :P :P :P


T

-- 
This sentence is false.
February 22, 2012
Re: Questions about windows support
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

-- 
Elegant or ugly code as well as fine or rude sentences have something in common: they don't depend on the language. -- Luca De Vitis
February 22, 2012
Re: Questions about windows support
"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message 
news:mailman.824.1329867308.20196.digitalmars-d@puremagic.com...
>
> You can do:
>
> program_name >/dev/null 2>&1 &
>
> That will silence everything. But yeah, too much typing, too much
> obscure stdout/stderr redirecting for a newbie to even begin to dream
> that such things are possible.
>
> A good default behaviour (for the app writer) is to fork() at startup,
> detach from pty in child, and then exit parent.  A couple o' programs do
> this.
>

Clever, I like it! I'm gonna try to remember that next time I start doing 
desktop-GUI stuff again.

>
> I'm pretty sure this is common knowledge, just that nobody bothers to do
> it. But I can dream. :)
>

It's news to me, but then again, I'm far from being a Linux veteran.

There are a *lot* of things to know about in Linux, though, and there's no 
standard learner's curriculum. I wouldn't be surprised if there's a lot of 
experienced Linux users that don't know at least one or two "basic" things. 
Hell I bet my knowledge is probably a mix of "some of the basics" and "some 
of the advanced".
February 22, 2012
Re: Questions about windows support
On Tue, Feb 21, 2012 at 06:49:45PM -0500, Nick Sabalausky wrote:
[...]
> I think that globbing should be done explicity by the app, *but* for
> apps that don't play ball you should be able to *explicitly* do it at
> the command line. Example:
> 
> $someutil *.txt foo.html
> ERROR: Can't find file '*.txt'
> $glob *.txt
> 'hello.txt' 'Modern File Name.txt' 'another.txt'
> $someutil `glob *.txt` foo.html
> Processing hello.txt...done
> Processing Modern File Name.txt...done
> Processing another.txt...done
> Processing foo.html...done

Hmm. I like that idea: have the shell *not* interpolate things by
default, unless you explicitly say to do so. So by default typing:

	rm *.txt

will pass "*.txt" to rm as a single argument, whereas:

	# Not real syntax:
	rm `*.txt`

will expand "*.txt" as a glob and pass the result to rm.


[...]
> Which brings up another little nitpick: When bash displays a prompt,
> it should first check to see if the last char output was a newline. If
> not, it should...ADD ONE!
[...]

Yeah I agree with that one. Unfortunately I don't think it can tell,
because the previous command writes to stdout directly (it doesn't go
through bash -- else it's be too inefficient, you'd have processes
copying stuff from each other all over the place). The terminal doesn't
let you ask "what was the last char sent to you?".

Having said that, though, the terminal *does* have an escape sequences
(yeah, ugh) that bash *could* use to find out where the cursor is, and
if it's not at column 0, insert a newline.

Unfortunately, us old hands have gotten so used to this misbehaviour
that we actually *use* it to detect whether something has a newline at
the end or not. Another of those historical accidents calcified before
it can be disinfected.


T

-- 
BREAKFAST.COM halted...Cereal Port Not Responding. -- YHL
February 22, 2012
Re: Questions about windows support
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????

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).


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

> 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.




I use a screen session for this stuff though.

window 0: the background noise controller
window 1: mutt
window 2: alsamixer
window 3: random notes to self for later

Usually, I only two two at a time. C-a a is the
best thing ever.

Then I use a separate screen for work things.



Now, here's something cool: from my laptop, running
Windows 7, I use putty to connect to the house.

But, here's what I did: it automatically runs screen,
with the escape set to s, rather than a, and a fixed
session name.

First off, C-s is easier to hit on the laptop than C-a
since the Fn key is on the far left, instead of ctrl.

So it is a more natural action anyway.


Aaaand I can run other screens inside!

screen -d -r ffmp3 # the one with mutt, etc
C-s c
screen -d -r work


Now, I can C-s s to swap between the two things...
and C-a a to swap sub tasks.


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.
February 22, 2012
Re: Questions about windows support
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


[...]
> > 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? ;-)


[...]
> > Ooooh! Another Apple II veteran! Ah, the good ole Apple II. Believe
> > it or not, my dad actually still has a couple o' 30-year-old Apple
> > II's that he actually *still uses*. He wrote a little personal
> > accounting app in Dbase, and has been using it for the last 3
> > decades. Never felt the need to upgrade. Of course, now he also has
> > a modern-day laptop and modern PCs in the office. But that old
> > faithful Apple II is still chugging away...
> >
> 
> Wow. Nice. I have an Apple IIc in a pile on the floor here to my
> right.  Haven't had time to play with it in forever though. It's the
> same model I grep up on (IIc), but not the same physical machine.
> *God* I wish I hadn't sold my floppies along with my original system.

Hmm. I'm really dating myself now, but I grew up with the *original*
Apple II, not even the IIc. I think I did get a IIc later on, but I got
caught up with IBM PCs around the time Macs started coming out. Haven't
been back to Apple since.


> I really wish I still had all that old data of mine. Probably all gone
> forever now: Overwritten, decayed, or in a landfill. :(

Well, even if you did have those old disks... they probably would've
demagnetized by now. Perhaps.

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..


> 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? :)


T

-- 
Just because you can, doesn't mean you should.
February 22, 2012
Re: Questions about windows support
"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message 
news:mailman.826.1329869015.20196.digitalmars-d@puremagic.com...
> On Tue, Feb 21, 2012 at 06:22:25PM -0500, Nick Sabalausky wrote:
> [...]
>> That hadn't occurred to me. Thanks. Normally, the only time I use
>> fg/bg is if I try to cancel something with Ctrl-blah and it suspends
>> the process instead of stopping it. So then I "fg [whatever num]" and
>> either try a different key combo or let it finish.
>
> 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.

But now that you mention it, I can definitely think of times when I could 
really make use of it. For instance, when browsing through the man page 
describing all the args for a command I'm using.

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. 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.

>> 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:

$sudo apt-get install foobar
versus:
$kdesudo kate /etc/some-system-config-file &

When you run a commandline tool with root privileges, you use "sudo". *But*, 
when you run a GUI app, you're supposed to use "kdesudo" or "gtksudo" (or is 
it "gsudo"?) instead. Apperently, launching a GUI app via "sudo" causes some 
ownership or permissions or something to be wrong even though it usually 
apears to work fine (I don't understand the details). That's what I mean: 
Shouldn't there just be *one* "sudo" that works properly for launching 
*both* GUI and commandline apps?

Shit, this whole thread is too damn addictive!
February 22, 2012
Re: Questions about windows support
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);
}


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

and etc.


Windows Powershell actually kinda works this way,
from what I know of it. You can do

ps | kill

and it works.



I almost *almost* want to write my own custom userland.
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.
February 22, 2012
Re: Questions about windows support
"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message 
news:mailman.829.1329869699.20196.digitalmars-d@puremagic.com...
> On Tue, Feb 21, 2012 at 06:49:45PM -0500, Nick Sabalausky wrote:
> [...]
>> I think that globbing should be done explicity by the app, *but* for
>> apps that don't play ball you should be able to *explicitly* do it at
>> the command line. Example:
>>
>> $someutil *.txt foo.html
>> ERROR: Can't find file '*.txt'
>> $glob *.txt
>> 'hello.txt' 'Modern File Name.txt' 'another.txt'
>> $someutil `glob *.txt` foo.html
>> Processing hello.txt...done
>> Processing Modern File Name.txt...done
>> Processing another.txt...done
>> Processing foo.html...done
>
> Hmm. I like that idea: have the shell *not* interpolate things by
> default, unless you explicitly say to do so. So by default typing:
>
> rm *.txt
>
> will pass "*.txt" to rm as a single argument, whereas:
>
> # Not real syntax:
> rm `*.txt`
>
> will expand "*.txt" as a glob and pass the result to rm.
>
>
> [...]
>> Which brings up another little nitpick: When bash displays a prompt,
>> it should first check to see if the last char output was a newline. If
>> not, it should...ADD ONE!
> [...]
>
> Yeah I agree with that one. Unfortunately I don't think it can tell,
> because the previous command writes to stdout directly (it doesn't go
> through bash -- else it's be too inefficient, you'd have processes
> copying stuff from each other all over the place). The terminal doesn't
> let you ask "what was the last char sent to you?".
>
> Having said that, though, the terminal *does* have an escape sequences
> (yeah, ugh) that bash *could* use to find out where the cursor is, and
> if it's not at column 0, insert a newline.
>
> Unfortunately, us old hands have gotten so used to this misbehaviour
> that we actually *use* it to detect whether something has a newline at
> the end or not. Another of those historical accidents calcified before
> it can be disinfected.
>

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:\>

C:\>cd foo

C:\foo\>

C:\foo\>

Instead of:

~$echo Hello > filea.txt
~$echo Hello > fileb.txt
~$
~$cd foo
~/foo$
~/foo$

But maybe that's not quite as bad?

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.

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 :/
3 4 5 6 7 8 9 10 11
Top | Discussion index | About this forum | D home