Hi, pretty new to the list though have been using cygwin for several months
now, first under win98, and now under XP.
This may have been covered elsewhere -- sorry, but I
doubt I will have enough time to read all the archives of
all the lists despite what the warnings say about 'do your
research for a day or two, first, then if you can't find the
answer post it, and very often have your answer in 5
minutes'. I thought the power of networking was that you
didn't have to do *everything* yourself, but you used a
network of collective knowledge to do more in less time...if
each of us had to write the cygwin toolset
ourselves...sheesh! But I know the 'sentiment' of having to
rehash the same basic questions again and again -- different
people have different levels of patience and tolerance for
such. Perhaps a 'newusers' list might allow for the
repetitious beginner type questions with those with more
patience staying on that list to answer possibly repetitive
questions. We don't have an "MVP" bonus-pat-on-the-head
program like in the MS-newsgroups. Sorta a smart idea of
MS's -- reward users with 'recognition' as MVP's for helping
newbies that might otherwise be asking those questions of MS
support people. A surreptitious way to recruit free
helpdesk volunteers! :-)
But to the main point....
I found creating a shortcut to bash (and calling it 'cygwin') seems to
shortcut the need for using cmd.exe. When I use the provided 'cygwin.bat', I
end
up with a process tree:
EXPLORER:
CMD.EXE
BASH.EXE
--- makes sense, shell cmd calls bash.exe -- but I noticed this annoying feature
--
if I had pressed 'control-c' sometime during my bash session, then when I hit
control-d to exit from bash, CMD would ask "do you really want to terminate this
BATCH job (y/n)?" Of course since it was at the end of the batch file, it
didn't
matter y or n, but it did requirement me to select an answer and hit return.
Being lazy, my first try at getting around this was to put 'start' in front of
the call to bash.exe. On WinXP, (and maybe win2k), the default on this has
changed
from being a "call <prog>; wait" to the equivalent of "call prog&" (no wait), so
the main cmd.exe would terminate and I'd be left with only BASH.EXE parented by
Explorer.
However, the purist in me wanted to know why I should call the CMD shell soley
for the purpose of calling the bash shell.
So..enter latest method: short cut to bash: in properties I have target:
"C:\root\bin\bash.exe --login -i" (root=cygwinroot), and the start-in dir
is set to C:\root\bin -- all like the batchfile would have done -- except this
is
a shortcut used directly by explorer -- no invocation of CMD --
*SO*, answering the original question: you can specify your starting dir as
\\<Mydomain (or server)>\home and end up with your domain home directory (if you
have one) or a exported 'home' dir on a local server. Since CMD is never in the
picture,
no complaints about it not liking UNC paths.
I don't have it setup fully yet, but I'm working toward making extensions ".sh",
".bsh"
and ".bash" all invoke the Bash script interpreter just like visual basic or
java
script are invoked on their shell languages. Then I should be able to just say
"foobar", where there is a "foobar.sh" in my path and I believe is should
transparently
use bash to interpret the results!
As an aid in all this, I put the normal cygwin directories in my path (put them
in the 'env' path entry in my current user tree -- I might want to have move
them
to HKLM so it's available for any user, but since I'm my only user right now, it
shouldn't make a difference.
I like the idea of creating a "Bash Here" context dir in the same vein as
"Command
Prompt Here" as suggested by Troy, but I'd likely try for a registry solution
over
the scripting solution -- seems more integrated with Winenv.
Anyone see any gotchas with my approach? Is there a reason/need for CMD.EXE to
stay resident in memory or be called before bash?
thanks,
newbie Linda
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
