"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!

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.

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

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

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

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.

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.

"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!

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.

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