On 10/27/06, Joel VanderWerf <vjoel / path.berkeley.edu> wrote:
> > I haven't. I've used VBA and built some pretty impressive (if fragile)
> > stuff on top of Access and Word, but I've never had to use full-on VB.
> > Maybe I *am* different than elsewhom participating in this thread: I use
> > the tool that's most appropriate to the environment. I was doing
>                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Tool choice is a tradeoff between:
>
> * most appropriate to the environment
> * most appropriate to the task
> * most appropriate to the user
>
> and maybe other factors as well. What this thread shows is that
> different combinations of env/task/user will make the tradeoff come out
> differently. No one size fits all.

By environment, I do *not* mean operating system. I mean the complex
intersection of operating system, task, user, and *other users* who
may have to deal with what I've written. For one-off stuff, I almost
always use irb.

For reusable stuff, I will generally use that which is platform
appropriate, if it applies to one platform. I'll use something truly
portable if it's got to be cross-platform.

That's what I mean; simply using Cygwin because you want to hide the
fact that you're on Windows is lazy *at best*. Using Cygwin because it
offers something that you absolutely must have to get your job done
and it doesn't exist in a native Windows version (or, in the case of X
before Xming, it's insanely priced) is pragmatic. It's much easier for
me to tell people "install this Windows application to get X working
if you're going to be working on the Unix machines" than "install this
whole environment and cross your fingers that your batch files always
work" (which, to be fair, they usually did; it's still not as easy as
Xming, though).

As I just said: I don't use cmd.exe because I love it. I use it
because I can take what I know from it and apply it to anyone else's
computer in the company.

Without having to get them to install Cygwin because I'm not
interested in feeling like I'm using Windows.

> and getting feedback that might prevent you from making a huge mistake.
> Maybe bash has this too, but I've never seen a way to turn it on. The
> same goes for wildcard completion:
>
> $ rm *.rb<tab>

I know in ksh and bash with vi mode (set -o vi) you can get that with <Esc><*>.

> > * Both have scripting languages; both scripting languages have some
> >  impressive capabilities. Bash's language is slightly more powerful,
> >  but both are like pulling teeth. I'd rather use Ruby, and both bash
> >  and cmd.exe treat these equally.
>
> Yes to the teeth simile.

On 10/27/06, Joel VanderWerf <vjoel / path.berkeley.edu> wrote:
> > There are other things, but by and large I find them both to be a wash
> > in the use. I don't even miss "screen" on Windows because it's trivial
> > to open another command window.
> But not trivial (even possible?), without screen, to detach from a
> session, move to another host, and reconnect to the session. Pls tell me
> I'm wrong...

If you use rdp it's trivial ;) Once enabled. However, that feature of
screen is related primarily to Unix pseudo-TTY support more than
anything else. Windows isn't designed to work that way.

And that's really the whole point, I guess.

-austin
-- 
Austin Ziegler * halostatue / gmail.com * http://www.halostatue.ca/
               * austin / halostatue.ca * http://www.halostatue.ca/feed/
               * austin / zieglers.ca