The one pronoun problem

R

Roedy Green

I was using a program called Goldwave to prepare a library of various
frog croaks. It drove me nearly nuts. To load the source file I had
to navigate through 7 jumps to get to the correct directory. I would
process the file clipping it, then I had to navigate though another 7
directories to get to the target directory to save it. Then back
another seven jumps to get to the directory for another source file.

I know, I could have loaded up more than one at a time, but this is a
general problem, in all computer OSes because the problem is inherited
from the structure of English.

In English there is only one HE pronoun. You can't talk about he1 and
he2. In windows there is only one current directory. There is not a
source and target directory or a dir1, dir2 and dir3 button every
where available to jump directly to some other common place.

In English you can reassign the meaning of HE at any without great
fuss. It should be similarly easy in the OS. You just Right click on
of he the "pronoun" buttons to say -- from now on, this button means
HERE -- this directory, this file, this place in the file, whenever I
left click it, take me here.

This needs to be a function universally supported in the same way in
every application.

I use Slick Edit that lets me roughly approximate this, at least
within the Slick Edit universe. I have some icons on the top bar I
can assign to macros. The problem is, to reassign the meaning of a
key, I have to compose a new macro, and go through a multikeystroke
sequence to assign the macro to the key. But from then on I can hop
from place to place with a single click. What is missing is easy way
to assign a PLACE to a button with a single click.

Perhaps as an addition there could be history of places you visited
(not counting the places you just passed through) so you can point and
click to recently visited other spots.


Why am I telling you this. Perhaps someone might like to write a
simple directory file/browser launcher, copier, deleter, renamer, much
like the old QDOS, that demonstrated the notion, perhaps evolving into
a Magellan-like tool with rapid file viewers. I would be nice to get
back to as good as it was under DOS.




--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes
 
R

Raymond DeCampo

Roedy said:
I was using a program called Goldwave to prepare a library of various
frog croaks. It drove me nearly nuts. To load the source file I had
to navigate through 7 jumps to get to the correct directory. I would
process the file clipping it, then I had to navigate though another 7
directories to get to the target directory to save it. Then back
another seven jumps to get to the directory for another source file.

I know, I could have loaded up more than one at a time, but this is a
general problem, in all computer OSes because the problem is inherited
from the structure of English.

In English there is only one HE pronoun. You can't talk about he1 and
he2. In windows there is only one current directory. There is not a
source and target directory or a dir1, dir2 and dir3 button every
where available to jump directly to some other common place.

That is not exactly true. In Windows you actually have a current
directory per drive and you can put this to good use.

E.g., suppose you have an XLST in C:\my\very\log\path\to\xslt and the
XML in P:\another\very\long\path\to\my\xml. You can do the following at
a command prompt:

C:\> cd \my\very\log\path\to\xslt
C:\my\very\log\path\to\xslt> P:
P:\> cd \another\very\long\path\to\my\xml
P:\another\very\long\path\to\my\xml> xalan -IN abc.xml -XSL C:xyz.xsl

Well, that's just great Ray, you say, if I have 20 partitions on my hard
drive. Well, that's where the "subst" command. The subst command
allows you to define a particular directory as a drive. E.g., perhaps
before you did the above you did

C:\> subst P: "C:\Documents and Settings\rgreen\My Documents\result"

Then P:\another\very\long\path\to\my\xml is really C:\Documents and
Settings\rgreen\My Documents\result\another\very\long\path\to\my\xml.

A few other commands you may want to investigate: cd /D, pushd, popd,
net use.
In English you can reassign the meaning of HE at any without great
fuss. It should be similarly easy in the OS. You just Right click on
of he the "pronoun" buttons to say -- from now on, this button means
HERE -- this directory, this file, this place in the file, whenever I
left click it, take me here.

This needs to be a function universally supported in the same way in
every application.

I use Slick Edit that lets me roughly approximate this, at least
within the Slick Edit universe. I have some icons on the top bar I
can assign to macros. The problem is, to reassign the meaning of a
key, I have to compose a new macro, and go through a multikeystroke
sequence to assign the macro to the key. But from then on I can hop
from place to place with a single click. What is missing is easy way
to assign a PLACE to a button with a single click.

Perhaps as an addition there could be history of places you visited
(not counting the places you just passed through) so you can point and
click to recently visited other spots.


Why am I telling you this. Perhaps someone might like to write a
simple directory file/browser launcher, copier, deleter, renamer, much
like the old QDOS, that demonstrated the notion, perhaps evolving into
a Magellan-like tool with rapid file viewers. I would be nice to get
back to as good as it was under DOS.

HTH,
Ray
 
R

Roedy Green

Well, that's just great Ray, you say, if I have 20 partitions on my hard
drive. Well, that's where the "subst" command. The subst command
allows you to define a particular directory as a drive. E.g., perhaps
before you did the above you did

brilliant. I never thought of using subst in a dynamic way. I will
have great fun with that.

IIRC there is a problem with Windows forgetting SUBST either when you
reboot or perhaps start a fresh command processor.

--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes
 
T

Tim Ward

Roedy Green said:
IIRC there is a problem with Windows forgetting SUBST either when you
reboot or perhaps start a fresh command processor.

There are other problems with SUBST. For reasons I haven't tried to research
it seems typical of source code control systems that they can't cope with
sets of files on SUBST "drives".
 
R

Raymond DeCampo

Roedy said:
brilliant. I never thought of using subst in a dynamic way. I will
have great fun with that.

IIRC there is a problem with Windows forgetting SUBST either when you
reboot or perhaps start a fresh command processor.

I routinely use it for my "My Documents" directory and I haven't had any
problems, although there are some gotchas. The drive *will* be un-subst
once you log out. To deal with that, just create a batch file that does
the subst commands you want and put a shortcut to it in your Startup folder.

There are some gotchas with subst and mapped drives. Important things
to remember are:
1) Drives are global, however, the mappings only live as long as your
current session
2) If you have scheduled tasks that run when you are not logged in, it
is not enough to run them as yourself to expect the mapped drives to be
there. Running a scheduled task as yourself is not the same as logging
in and then running the task.

HTH,
Ray
 
R

Roedy Green

There are other problems with SUBST. For reasons I haven't tried to research
it seems typical of source code control systems that they can't cope with
sets of files on SUBST "drives".

the other thing is you cant use .. to get to the real super directory.
This confuses the heck out of my custom web building software that is
building cross links all over when you give it filenames of subtrees
that don't hint at the parent.

--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes
 
C

christopher

My graphics editing program keeps separate default directories for
save, save as, and save copy as. Also, if you are opening from
removable media and remove it, the save defaults to your last save
rather than someplace meaningless.

In your case, burn the files to a CD, read them all in and pop out the
CD, save them wherever windows defaults, and move them all after.
-- clh
 
B

blmblm

There's a concept of "current directory" in Windows? My experience has
been that too many applications don't give me any choice about the
starting point for file-chooser menus; instead they always start at
the same place ("My Computer", or "Personal Documents", or something).
Is there some trick I don't know about that would help ....?
There is not a
source and target directory or a dir1, dir2 and dir3 button every
where available to jump directly to some other common place.

That is not exactly true. In Windows you actually have a current
directory per drive and you can put this to good use.
[ snip ]

A few other commands you may want to investigate: cd /D, pushd, popd,
net use.

Well! I thought it was only "real shells" (translation: Unix-type
shells) that provided this kind of functionality. Interesting.
Something to remember next time I try to do stuff with Windows.

This probably doesn't help Roedy, but in the Unix CLI world, I suspect
most shells provide a "stack" of recently visited directories and
commands to manipulate them (in bash, pushd and popd are relevant
commands), plus the ability to define and use environment variables
that point to directories -- e.g.,

[ .... navigate to first directory of interest .... ]
HERE=`pwd` ; export HERE
[ .... navigate to second directory of interest .... ]
THERE=`pwd` ; export THERE

and then to copy a file from the first to the second directory,
cp $HERE/file $THERE

Hear, hear. Or as good as it is in Unix CLI-land .... Yeah, I'm
biased. :)
 
A

Andrew Thompson

There's a concept of "current directory" in Windows?
System.getProperty("user.dir")

Is there some trick I don't know about that would help ....?

JFileChooser(File)/FileDialog.setDirectory(File)

HTH
 
B

blmblm

JFileChooser(File)/FileDialog.setDirectory(File)

HTH

Sounds very useful if one is writing Java code to run under Windows,
but I was asking more in reference to using existing applications
(e.g., MS Office). I'm guessing that some of them do have some notion
of "current directory" that can maybe be changed via a command-line
parameter, but the whole notion of "current directory" seems to be
sort of alien to the GUI way of doing things. IMO, of course.
 
C

Chris Smith

Sounds very useful if one is writing Java code to run under Windows,
but I was asking more in reference to using existing applications
(e.g., MS Office). I'm guessing that some of them do have some notion
of "current directory" that can maybe be changed via a command-line
parameter, but the whole notion of "current directory" seems to be
sort of alien to the GUI way of doing things. IMO, of course.

Nevertheless, the current directory does exist in Windows. You don't
generally change it with a command line parameter. Every Windows
application shortcut has a property for what directory it starts in.
Whether the application uses the current working directory for anything
or not is up to that application.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 
R

Raymond DeCampo

Andrew said:
System.getProperty("user.dir")

This gives the user's home directory, which is a different concept from
the current directory. To get the current directory, use new File(".").
JFileChooser(File)/FileDialog.setDirectory(File)

HTH

Ray
 
B

blmblm

Nevertheless, the current directory does exist in Windows. You don't
generally change it with a command line parameter. Every Windows
application shortcut has a property for what directory it starts in.
Whether the application uses the current working directory for anything
or not is up to that application.

I feel like we're not speaking quite the same language here. What I
mean by "current directory" is what you're likely to get with the
typical text-based Unix program launched from a command shell --
it can be different every time the program runs, and it's the basis
for specifying relative pathnames for the user's files. This is the
concept I find lacking in most GUIs, independent of operating system
(and I'm wondering whether it's because it's really not there, or
it's there and I just don't know how to get at it).

In contrast to this thing I'm calling "current directory", one
of these text-based programs might also have some notion of a home
directory (for itself), where it would find, oh, help files and such.
This directory would be the same for every invocation of the program.
It sounds like what you're calling the "current directory" for a
Windows application is more like this thing I'm calling "home directory
for itself" -- the same every time you launch the program, and hence
not so useful (IMO) as a starting point for relative pathnames for the
user's files.

But maybe I'm still not getting it?
 
C

Chris Smith

I feel like we're not speaking quite the same language here. What I
mean by "current directory" is what you're likely to get with the
typical text-based Unix program launched from a command shell --
it can be different every time the program runs, and it's the basis
for specifying relative pathnames for the user's files.

Yes, that is also what I mean by "current directory". If you run a
Windows application from the command shell, then it will start out with
the same current working directory as the shell that started it, exactly
as with UNIX shell commands. I mentioned the shortcut thing only to
mention that, when you launch a Windows application from the Start menu,
for example, there still *is* a current working directory, even though
it's slightly more troublesome to change it (you'd have to edit the
shortcut from the Start menu). The concept still exists, but it is
slightly more hidden.

The current working directory is *not* an application-private thing.
It's not something that a process can choose to not implement. It is
always there, whether the application pays attention to it or not.
Several Win32 API and C standard library functions (and many other
libraries built on them) use it to resolve relative path names. The
JVM's File class uses it to resolve relative path names. Even though
the Windows task manager won't show it, I typically run a third-party
task manager application on Windows XP called TaskInfo, and it will tell
me the current working directory of any process I choose.

That's the current working directory, and it's what you get from
System.getProperty("user.dir").

Of course, an application can ignore its current working directory, and
many GUI applications do exactly that. Looking through TaskInfo, most
applications end up having the current working directory set to the
directory that contains their executable file, probably because that's
the default if you launch the application from a GUI interface and don't
specify anything different.
This is the concept I find lacking in most GUIs.

Do you mean that you find the concept neglected in the user interface?
That's certainly true. It still exists, though, but is just slightly
behind the scenes.
In contrast to this thing I'm calling "current directory", one
of these text-based programs might also have some notion of a home
directory (for itself) [...]

That is definitely different from the current working directory, and I'm
not talking about anything like that.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 
R

Raymond DeCampo

I feel like we're not speaking quite the same language here. What I
mean by "current directory" is what you're likely to get with the
typical text-based Unix program launched from a command shell --
it can be different every time the program runs, and it's the basis
for specifying relative pathnames for the user's files. This is the
concept I find lacking in most GUIs, independent of operating system
(and I'm wondering whether it's because it's really not there, or
it's there and I just don't know how to get at it).

In contrast to this thing I'm calling "current directory", one
of these text-based programs might also have some notion of a home
directory (for itself), where it would find, oh, help files and such.
This directory would be the same for every invocation of the program.
It sounds like what you're calling the "current directory" for a
Windows application is more like this thing I'm calling "home directory
for itself" -- the same every time you launch the program, and hence
not so useful (IMO) as a starting point for relative pathnames for the
user's files.

But maybe I'm still not getting it?

Windows does have the concept of a current directory. When it comes to
invoking shortcuts, the current directory of the process is set by the
shortcut. (That way you could set it to a useful place -- otherwise it
would be hardcoded and useless.) However, most Windows programs when
displaying a file chooser dialog, will start with the user's home
directory, the C:\ directory or My Computer. That is an issue with the
specific application, not the OS.

Ray
 
B

blmblm

Yes, that is also what I mean by "current directory". If you run a
Windows application from the command shell, then it will start out with
the same current working directory as the shell that started it, exactly
as with UNIX shell commands. I mentioned the shortcut thing only to
mention that, when you launch a Windows application from the Start menu,
for example, there still *is* a current working directory, even though
it's slightly more troublesome to change it (you'd have to edit the
shortcut from the Start menu). The concept still exists, but it is
slightly more hidden.

The current working directory is *not* an application-private thing.
It's not something that a process can choose to not implement. It is
always there, whether the application pays attention to it or not.
Several Win32 API and C standard library functions (and many other
libraries built on them) use it to resolve relative path names. The
JVM's File class uses it to resolve relative path names. Even though
the Windows task manager won't show it, I typically run a third-party
task manager application on Windows XP called TaskInfo, and it will tell
me the current working directory of any process I choose.

That's the current working directory, and it's what you get from
System.getProperty("user.dir").

Of course, an application can ignore its current working directory, and
many GUI applications do exactly that. Looking through TaskInfo, most
applications end up having the current working directory set to the
directory that contains their executable file, probably because that's
the default if you launch the application from a GUI interface and don't
specify anything different.


Do you mean that you find the concept neglected in the user interface?
Yes, that's what I mean -- neglected to the point where it wasn't
obvious to me that it even existed. I asked in part because I wondered
if it really *was* there, but I wasn't noticing because I didn't know
the right incantations to invoke the behavior I want. From what you
say, though, it sounds like some application don't make use of it, so
maybe there are no such incantations ....

That aside, it does seem like maybe the whole idea isn't that useful
unless (1) the program is being launched from a command shell, which
now that I think of it I'm not sure I've ever done for a GUI-based
program under Windows, and/or (2) the program allows it be changed
during execution.
That's certainly true. It still exists, though, but is just slightly
behind the scenes.
In contrast to this thing I'm calling "current directory", one
of these text-based programs might also have some notion of a home
directory (for itself) [...]

That is definitely different from the current working directory, and I'm
not talking about anything like that.

Okay -- though if most applications just set the CWD to the directory
in which the executable lives, it could come to the same thing, no?

Anyway, thanks for the info -- not entirely on-topic for this group,
but helpful to me and perhaps some other lurkers.
 
B

blmblm

Windows does have the concept of a current directory. When it comes to
invoking shortcuts, the current directory of the process is set by the
shortcut. (That way you could set it to a useful place -- otherwise it
would be hardcoded and useless.) However, most Windows programs when
displaying a file chooser dialog, will start with the user's home
directory, the C:\ directory or My Computer. That is an issue with the
specific application, not the OS.

As I said in my response to the other reply (from Chris Smith) --
okay, this makes sense, and thanks!
 
R

Raymond DeCampo

Raymond said:
This gives the user's home directory, which is a different concept from
the current directory. To get the current directory, use new File(".").

My bad, I did not read the post carefully enough. I read "user.dir" and
my mind saw "user.home"...my apologies.

Ray
 
C

Chris Smith

That aside, it does seem like maybe the whole idea isn't that useful
unless (1) the program is being launched from a command shell, which
now that I think of it I'm not sure I've ever done for a GUI-based
program under Windows, and/or (2) the program allows it be changed
during execution.

Yep. Regarding #2, I'm not even aware of a GUI app that actually
changes the current working directory. Generally, when a GUI app allows
you change some kind of default directory, it's keeping some private
directory in mind that's actually *not* the OS's idea of the CWD.
Okay -- though if most applications just set the CWD to the directory
in which the executable lives, it could come to the same thing, no?

Sort of, but it's never really safe to assume that the CWD will be the
directory containing the executable. I *do* very occasionally launch
GUI apps from a command line, and I'd be a bit peeved if they broke when
I did so.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,904
Latest member
HealthyVisionsCBDPrice

Latest Threads

Top