Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #29803 > unrolled thread

A "current directory" concept for Java...

Back to article view | Back to comp.lang.java.programmer

Contents

  A "current directory" concept for Java... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-22 16:49 +0000
    Re: A "current directory" concept for Java... Jeff Higgins <jeff@invalid.invalid> - 2014-08-22 14:50 -0400
    Re: A "current directory" concept for Java... Jeff Higgins <jeff@invalid.invalid> - 2014-08-22 15:10 -0400
    Re: A "current directory" concept for Java... Martin Gregorie <martin@address-in-sig.invalid> - 2014-08-22 19:26 +0000
      Re: A "current directory" concept for Java... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-22 23:38 +0000
        Re: A "current directory" concept for Java... Martin Gregorie <martin@address-in-sig.invalid> - 2014-08-23 14:24 +0000
          Re: A "current directory" concept for Java... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-23 16:31 +0000
            Re: A "current directory" concept for Java... Martin Gregorie <martin@address-in-sig.invalid> - 2014-08-23 19:34 +0000
              Re: A "current directory" concept for Java... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-24 08:42 +0000
                Re: A "current directory" concept for Java... Martin Gregorie <martin@address-in-sig.invalid> - 2014-08-24 10:37 +0000
                  Re: A "current directory" concept for Java... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-24 13:41 +0000
                    Re: A "current directory" concept for Java... Martin Gregorie <martin@address-in-sig.invalid> - 2014-08-24 18:33 +0000
                      Re: A "current directory" concept for Java... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-24 22:33 +0000
                        Re: A "current directory" concept for Java... Martin Gregorie <martin@address-in-sig.invalid> - 2014-08-25 00:14 +0000
    Re: A "current directory" concept for Java... Jeff Higgins <jeff@invalid.invalid> - 2014-08-22 19:45 -0400
      Re: A "current directory" concept for Java... Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-23 15:32 +0000
        Re: A "current directory" concept for Java... Jeff Higgins <jeff@invalid.invalid> - 2014-08-23 12:49 -0400
        Re: A "current directory" concept for Java... Jeff Higgins <jeff@invalid.invalid> - 2014-08-23 17:40 -0400
    Re: A "current directory" concept for Java... Jan Burse <janburse@fastmail.fm> - 2014-08-23 10:31 +0200
      With new Path (Re: A "current directory" concept for Java...) Jan Burse <janburse@fastmail.fm> - 2014-08-23 10:48 +0200
        Re: With new Path (Re: A "current directory" concept for Java...) Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2014-08-23 14:38 +0000
    Re: A "current directory" concept for Java... Roedy Green <see_website@mindprod.com.invalid> - 2014-08-23 05:31 -0700

Page 1 of 2  [1] 2  Next page →

#29803 — A "current directory" concept for Java...

I'm fully aware, that the concept of a mutable "current directory"
for the whole VM does not work at all well with threads, and thus
there is of course no such thing like "System.chDir(...)" in Java.

Instead, I'd like to use a mutable Wrapper for java.nio.file.Path
and whereever I need to access a file, I'd call a method on the 
wrapper and that would check, if the file's path is a relative 
or an absolute one, and eventually join it with the wrapped Path
object. The wrapper itself then could offer something like a chDir()
method to replace its wrapped Path by a target Path after following
a series of ".."(for stepping up to the Parent-dir), or subfolders.

e.g.: the wrapped Path of curDir originally points to "/tmp", then...
 - curDir.chDir("foo") would go to "/tmp/foo", then
 - curDir.chDir("../bar") would go to "/tmp/bar", then
 - curDir.chDir("/foo") would go to "/foo"
Whether it would check the file system about each of these
paths, and whether it would resolve symlinks or just use them 
verbatim, is not among the things I care for at this point.

With that, the concept of "current directory" would be tied to
a particular "curDir" object, and the user would be responsible
to either keep it to a single thread, or at least care about 
proper synchronisation across threads (as with all mutable objects).

I had a look at the classes/interfaces in java.(n)io, but couldn't
find such a class. Is it not there, or did I just miss it?

While it wouldn't be too hard to implement it for a particular
platform, getting it right for different platforms (maybe even 
platforms where absolute/relative paths follow different patterns)
would be tricky enough, that I'd rather use a library classes (if
one exists), than roll my own.

PS: Java 7 here

[toc] | [next] | [standalone]

#29805

On 08/22/2014 12:49 PM, Andreas Leitgeb wrote:
> I'm fully aware, that the concept of a mutable "current directory"
> for the whole VM does not work at all well with threads, and thus
> there is of course no such thing like "System.chDir(...)" in Java.
>
> Instead, I'd like to use a mutable Wrapper for java.nio.file.Path
> and whereever I need to access a file, I'd call a method on the
> wrapper and that would check, if the file's path is a relative
> or an absolute one, and eventually join it with the wrapped Path
> object. The wrapper itself then could offer something like a chDir()
> method to replace its wrapped Path by a target Path after following
> a series of ".."(for stepping up to the Parent-dir), or subfolders.
>
> e.g.: the wrapped Path of curDir originally points to "/tmp", then...
>   - curDir.chDir("foo") would go to "/tmp/foo", then
>   - curDir.chDir("../bar") would go to "/tmp/bar", then
>   - curDir.chDir("/foo") would go to "/foo"
> Whether it would check the file system about each of these
> paths, and whether it would resolve symlinks or just use them
> verbatim, is not among the things I care for at this point.
>
> With that, the concept of "current directory" would be tied to
> a particular "curDir" object, and the user would be responsible
> to either keep it to a single thread, or at least care about
> proper synchronisation across threads (as with all mutable objects).
>
> I had a look at the classes/interfaces in java.(n)io, but couldn't
> find such a class. Is it not there, or did I just miss it?
>
> While it wouldn't be too hard to implement it for a particular
> platform, getting it right for different platforms (maybe even
> platforms where absolute/relative paths follow different patterns)
> would be tricky enough, that I'd rather use a library classes (if
> one exists), than roll my own.

Yep, very likely given:
<http://docs.oracle.com/javase/7/docs/api/java/nio/file/FileSystem.html#getPathMatcher(java.lang.String)>
>
> PS: Java 7 here
>

[toc] | [prev] | [next] | [standalone]

#29806

On 08/22/2014 12:49 PM, Andreas Leitgeb wrote:
> I'm fully aware, that the concept of a mutable "current directory"
> for the whole VM does not work at all well with threads, and thus
> there is of course no such thing like "System.chDir(...)" in Java.
>
> Instead, I'd like to use a mutable Wrapper for java.nio.file.Path
> and whereever I need to access a file, I'd call a method on the
> wrapper and that would check, if the file's path is a relative
> or an absolute one, and eventually join it with the wrapped Path
> object. The wrapper itself then could offer something like a chDir()
> method to replace its wrapped Path by a target Path after following
> a series of ".."(for stepping up to the Parent-dir), or subfolders.
>
> e.g.: the wrapped Path of curDir originally points to "/tmp", then...
>   - curDir.chDir("foo") would go to "/tmp/foo", then
>   - curDir.chDir("../bar") would go to "/tmp/bar", then
>   - curDir.chDir("/foo") would go to "/foo"
> Whether it would check the file system about each of these
> paths, and whether it would resolve symlinks or just use them
> verbatim, is not among the things I care for at this point.
>
> With that, the concept of "current directory" would be tied to
> a particular "curDir" object, and the user would be responsible
> to either keep it to a single thread, or at least care about
> proper synchronisation across threads (as with all mutable objects).

A chroot() method might add complexity.

> I had a look at the classes/interfaces in java.(n)io, but couldn't
> find such a class. Is it not there, or did I just miss it?
>
> While it wouldn't be too hard to implement it for a particular
> platform, getting it right for different platforms (maybe even
> platforms where absolute/relative paths follow different patterns)
> would be tricky enough, that I'd rather use a library classes (if
> one exists), than roll my own.
>
> PS: Java 7 here
>

[toc] | [prev] | [next] | [standalone]

#29807

On Fri, 22 Aug 2014 16:49:12 +0000, Andreas Leitgeb wrote:

> I'm fully aware, that the concept of a mutable "current directory" for
> the whole VM does not work at all well with threads, and thus there is
> of course no such thing like "System.chDir(...)" in Java.
>
Unless I missed something, on a Unix/Linux system the Java 'current 
directory' is the directory in $PWD when the JVM is started and all 
relative filenames are relative to $PWD. I filename os relative unless it 
starts with '/'. Isn't it the same on a Windows box except that an 
absolute name will start with a drive designator?

Apart from that, anything else I've needed can be achieved by judicious 
use of the File class. At least, that's been my experience and I've 
written command line Java programs that walk directory structures 
examining the files and directories they find there and applying 
appropriate actions.



-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#29812

Martin Gregorie <martin@address-in-sig.invalid> wrote:
> On Fri, 22 Aug 2014 16:49:12 +0000, Andreas Leitgeb wrote:
>> I'm fully aware, that the concept of a mutable "current directory" for
>> the whole VM does not work at all well with threads, and thus there is
>> of course no such thing like "System.chDir(...)" in Java.
> Unless I missed something, on a Unix/Linux system the Java 'current 
> directory' is the directory in $PWD when the JVM is started and all 
> relative filenames are relative to $PWD.

That's typically the initial value for the "current directory."
In most languages this can be changed lateron, and in some of
those other languages this interferes badly with threads, which
I believe is the reason, why Java doesn't allow it to be changed
lateron.

> I filename os
"A filename is ..." ?
>                relative unless it 
> starts with '/'. Isn't it the same on a Windows box except that an 
> absolute name will start with a drive designator?

Well, you already named the first exception: drive letters...
Old MacOS (pre-X) had relative paths start with the separator char ":"
and had no special name to denote "parent" at all (but fortunately,
that's mere archaeology by now).

Since writing my previous post, I've found that the non-trivial parts
of what I sought for already exist as Path.resolve().
<http://docs.oracle.com/javase/7/docs/api/java/nio/file/Path.html#resolve(java.lang.String)>
Now, all left to do for a chDir is:  curDir = curDir.resolve(relOrAbsPath);
(and maybe curDir = curDir.toRealPath();)

> Apart from that, anything else I've needed can be achieved by judicious 
> use of the File class. At least, that's been my experience and I've 
> written command line Java programs that walk directory structures 
> examining the files and directories they find there and applying 
> appropriate actions.

I'll need to emulate some kind of current directory, and will need to
manually join user-provided relative paths (typically bare filenames)
to that current directory for various uses (open,remove,rename,...).
Eventually I need to spawn processes, which then need that emulated
current directory to be their initial real current directory.

[toc] | [prev] | [next] | [standalone]

#29821

On Fri, 22 Aug 2014 23:38:43 +0000, Andreas Leitgeb wrote:

> I'll need to emulate some kind of current directory,
>
If you haven't already done so, take a look at File.listFiles() and its 
filter-equipped siblings. Those are what I've used when I've needed the 
equivalent of C's directory reading functions. The File[] array they 
return isn't in any particular order, but then neither are the files that 
repeated calls to the readdir() function returns.
 
> and will need to
> manually join user-provided relative paths (typically bare filenames)
> to that current directory for various uses (open,remove,rename,...).
>
>
easy enough using a recursive method with a File argument. Something like 
this does the trick if you want to walk a directory tree looking at all 
the files in it:

void processDirectory(File dir)
{
   File flist[] = f.listFiles();
   for (int i = 0; i < flist.length; i++
   {
      if (flist[i].isDirectory())
         processDirectory(new File(dir, flist[i].getName()));
      else
      { /* Deal with the files in the list. */ }
   }
}

> Eventually I need to spawn processes, which then need that emulated
> current directory to be their initial real current directory.
>
Do these have to be Java processes?


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#29825

Martin Gregorie <martin@address-in-sig.invalid> wrote:
> On Fri, 22 Aug 2014 23:38:43 +0000, Andreas Leitgeb wrote:
>> I'll need to emulate some kind of current directory,
> If you haven't already done so, take a look at File.listFiles() and its 
> filter-equipped siblings.

Yep, I think I also missed that in Path...  Good to know
that I'll just have to use (good old) java.io for that.

>> Eventually I need to spawn processes, which then need that emulated
>> current directory to be their initial real current directory.
> Do these have to be Java processes?

No.
At least, I already found myself, how to pass a directory to the
ProcessBuilder. :)

[toc] | [prev] | [next] | [standalone]

#29827

On Sat, 23 Aug 2014 16:31:36 +0000, Andreas Leitgeb wrote:

> Martin Gregorie <martin@address-in-sig.invalid> wrote:
>> On Fri, 22 Aug 2014 23:38:43 +0000, Andreas Leitgeb wrote:
>>> I'll need to emulate some kind of current directory,
>> If you haven't already done so, take a look at File.listFiles() and its
>> filter-equipped siblings.
> 
> Yep, I think I also missed that in Path...  Good to know that I'll just
> have to use (good old) java.io for that.
> 
>>> Eventually I need to spawn processes, which then need that emulated
>>> current directory to be their initial real current directory.
>> Do these have to be Java processes?
> 
> No.
> At least, I already found myself, how to pass a directory to the
> ProcessBuilder. :)
>
Cool. It all looks straightforward - at least for UNIX/Linux. To run 
'myprocess' against each file in the directory you'd modify my 
processDirectory method to look like this:

void processDirectory(File dir)
{
   File flist[] = f.listFiles();
   for (int i = 0; i < flist.length; i++
   {
      if (flist[i].isDirectory())
         processDirectory(new File(dir, flist[i].getName()));
      else 
      {
         ProcessBuilder pb = new ProcessBuilder("myprocess", 
                                                flist[i].getname());
         pb.directory(dir);
         Process p = pb.start();
         /* deal with process i/o streams */
         int exitValue = p.waitFor();
         /* see if the process exited normally */
      }
   }
}

It looks to me as if ProcessBuilder is very similar to C's exec() 
functions. The above is not intentionally teaching you to suck eggs: 
apologies if you already know what it shows. Apart from the point that 
there doesn't seem to be any way to make connections to the new Process's 
i/o streams before the command it controls starts to execute I can see 
only one bijou snaggette which might affect code portability: the meaning 
of 'current directory'.

In a UNIX/Linux environment relative file names are relative to the 
directory the user is in when a command is issued, but in at least some 
circumstances Windows programs act as though the 'current directory' is 
the one the program was loaded from. I've noticed this difference when 
running Windows programs on a Linux box under Wine but am unclear when it 
occurs: might it apply when a program is launched by clicking an icon but 
not when its launched from a command line or a user-written CMD file?


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#29832

Martin Gregorie <martin@address-in-sig.invalid> wrote:
>          ProcessBuilder pb = new ProcessBuilder("myprocess", 
>                                                 flist[i].getname());
>          pb.directory(dir);
>          Process p = pb.start();
>          /* deal with process i/o streams */
>          int exitValue = p.waitFor();
>
>                                              Apart from the point that 
> there doesn't seem to be any way to make connections to the new Process's 
> i/o streams before the command it controls starts to execute ...

That's not quite the "whole" truth ;-)
ProcessBuilder has a couple of methods to tell what to do with spawnee's
streams. You can set them up to be redirected to current process's streams,
cause them to be redirected to files and some more options.

It's only when you keep it at default, then it is set up for pipe-streams
and what you then do with the created Process is merely pick up your side
of these established streams.

> In a UNIX/Linux environment relative file names are relative to the 
> directory the user is in when a command is issued, but in at least some 
> circumstances Windows programs act as though the 'current directory' is 
> the one the program was loaded from.  I've noticed this difference when 
> running Windows programs on a Linux box under Wine but am unclear when it 
> occurs: might it apply when a program is launched by clicking an icon but 
> not when its launched from a command line or a user-written CMD file?

Could be a legacy from old Dos-days, where installed programs often
expected to be invoked from their installation directory.  Thats when 
one had a couple of .bat files for each application, that would cd to
the respective one's installation dir and then start the application.

[toc] | [prev] | [next] | [standalone]

#29834

On Sun, 24 Aug 2014 08:42:02 +0000, Andreas Leitgeb wrote:

> That's not quite the "whole" truth ;-)
>
Quite probably not, so I obviously messed something.

> ProcessBuilder has a couple of methods to tell what to do with spawnee's
> streams. You can set them up to be redirected to current process's
> streams,
> cause them to be redirected to files and some more options.
>
What I was commenting about is that calling ProcessBuilder.start() 
creates a Process and must start the load and process it controls since 
there is apparently no Process.start or Process.run method. I was 
expecting to have either: 

- a way of redirecting the standard streams provided by ProcessBuilder 
  as well as the redirectErrorStream() switch that would do the job
  before ProcessBuilder.start is called

- the ability to use the Process.getXXXStream() methods before calling
  a method that would allow the Process to run. 

Instead, I don't see either of these, so what have I missed?

  
> It's only when you keep it at default, then it is set up for
> pipe-streams and what you then do with the created Process is merely
> pick up your side of these established streams.
>
So, you are saying that the Process actually runs for a short time until 
it either wants input or fills an output buffer and then blocks until the 
streams have been redirected via the getXXXStream() methods? If so, that 
seems like a somewhat mickey mouse approach.

> Could be a legacy from old Dos-days, where installed programs often
> expected to be invoked from their installation directory.  Thats when
> one had a couple of .bat files for each application, that would cd to
> the respective one's installation dir and then start the application.
>
Agreed. I haven't done much/any programming in the Windows environment 
since W95, so what is the default these days for command line/scripted 
execution or for running a program via an icon click? Does the current 
working directory have the same default in both cases and, if so, can you 
tell me what it is: this may be useful stuff to know for code portability 
reasons.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#29839

Martin Gregorie <martin@address-in-sig.invalid> wrote:
> On Sun, 24 Aug 2014 08:42:02 +0000, Andreas Leitgeb wrote:
>> ProcessBuilder has a couple of methods to tell what to do with spawnee's
>> streams. You can set them up to be redirected to current process's
>> streams, cause them to be redirected to files and some more options.
> What I was commenting about is that calling ProcessBuilder.start() 
> creates a Process and must start the load and process it controls since 
> there is apparently no Process.start or Process.run method.

ProcessBuilder.start() really starts the new Process.

> I was expecting to have either: 
> - a way of redirecting the standard streams provided by ProcessBuilder 
>   as well as the redirectErrorStream() switch that would do the job
>   before ProcessBuilder.start is called
> - the ability to use the Process.getXXXStream() methods before calling
>   a method that would allow the Process to run. 

The redirection is always done with redirectXxx() methods of ProcessBuilder.

If you redirect to a file, then the started Process will instantly see
its respective standard descriptor connected to that file.

If you redirect to "INHERIT", then the started Process will instantly
see its respective standard descriptor connected to whatever its parent's
respective descriptor is tied to.

If you redirect to a pipe (which is the case if you don't call any
of ProcessBuilder's redirectXxx methods), then the started Process will
instantly see its respective standard descriptor connected to some pipe.

The only thing that appears to me as missing is, when I'd like to tie
one Process's output to another Process's input. I must admit that
I haven't seen (nor needed, nor googled) that case, yet.

>> It's only when you keep it at default, then it is set up for
>> pipe-streams and what you then do with the created Process is merely
>> pick up your side of these established streams.
> So, you are saying that the Process actually runs for a short time until 
> it either wants input or fills an output buffer and then blocks ...

so far: yes

> until the streams have been redirected via the getXXXStream() methods?

Streams aren't "redirected" by calling getXXXStream(). These
streams already(from start) have been directed to some pipe.
With getXXXStream() you just obtain a handle to that pipe, almost
in the same way as  System.in  gives you a handle to current 
Process' own stdin.  (That's what I meant with "picking up"
parent's own end of the pipe.)

> If so, that seems like a somewhat mickey mouse approach.

The only bit missing (and I'm not sure if it is really missing)
is, that I can't short-circuit two sub-Process' pipes.  All pipes
defined through ProcessBuilder.redirectXxx() are between parent and
child, not between two sibling childs.

>> Could be a legacy from old Dos-days, where installed programs often
>> expected to be invoked from their installation directory.  Thats when
>> one had a couple of .bat files for each application, that would cd to
>> the respective one's installation dir and then start the application.
> Agreed. I haven't done much/any programming in the Windows environment 
> since W95, 
I left that world already in the days of 3.1 in favour of
version 0.99pl14 of a different, rather new kernel back then.

My guesstimate would be: if a process is started from shell, then
the user has a specific expectation about its "current" dir, and
any words passed as arguments could be relative paths (even if not
(yet) existing as files) and therefore the current dir would need
to be the current directory of the shell.
Otoh, if a program is started through double click of a File whose
type is associated to the Program, then the program only gets an
absolute Path, and thus the current dir is "by definition" irrelevant.
A third case is, when a Program gets started through a double-click
on its own icon or a shortcut/link-icon.
I have no idea what current dir to expect there. Fortunately for me,
these cases are not relevant to my projects at hand ;-)

[toc] | [prev] | [next] | [standalone]

#29841

On Sun, 24 Aug 2014 13:41:18 +0000, Andreas Leitgeb wrote:

>> I was expecting to have either:
>> - a way of redirecting the standard streams provided by ProcessBuilder
>>   as well as the redirectErrorStream() switch that would do the job
>>   before ProcessBuilder.start is called
>> - the ability to use the Process.getXXXStream() methods before calling
>>   a method that would allow the Process to run.
> 
> The redirection is always done with redirectXxx() methods of
> ProcessBuilder.
>
The only one I can see documented is redirectErrorStream() and that only 
determines whether stderr output is redirected to stdout or not.

Everything else is apparently handled via Process.getXXXStream() methods, 
which surprised me.

> The only thing that appears to me as missing is, when I'd like to tie
> one Process's output to another Process's input. I must admit that I
> haven't seen (nor needed, nor googled) that case, yet.
>
I've run into similar problems with JDBC and when handling blobs and 
clobs: sometimes it seems as if it would be nice to have some sort of 
DataPump object that could be installed between the data source and sink: 
I ended up running the data into a ByreArray as a temp store and then 
pulling it over into the object I needed to manipulate it in.

> so far: yes
> 
>> until the streams have been redirected via the getXXXStream() methods?
> 
> Streams aren't "redirected" by calling getXXXStream(). These streams
> already(from start) have been directed to some pipe.
>
Understood: loose terminology on my part.

> My guesstimate would be: if a process is started from shell, then the
> user has a specific expectation about its "current" dir, and any words
> passed as arguments could be relative paths (even if not (yet) existing
> as files) and therefore the current dir would need to be the current
> directory of the shell.
> Otoh, if a program is started through double click of a File whose type
> is associated to the Program, then the program only gets an absolute
> Path, and thus the current dir is "by definition" irrelevant.
> A third case is, when a Program gets started through a double-click on
> its own icon or a shortcut/link-icon.
>
Yes. I think cases 2 and three are the same: the program thinks other 
files in its installation directory are local to it and anything else has 
to use absolute pathnames. It doesn't matter whether they were clicked on 
in Exploder or selected through the file chooser: the program requires 
absolute pathnames to access them. This becomes quite obvious when you 
write shell scripts that run Windows apps running under Wine.

> I have no idea what current dir to expect there. Fortunately for me,
> these cases are not relevant to my projects at hand ;-)
>
That's good. I only piped up because I wasn't sure if the apps you speak 
of would need to be runnable in a Windows environment


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#29843

Martin Gregorie <martin@address-in-sig.invalid> wrote:
> On Sun, 24 Aug 2014 13:41:18 +0000, Andreas Leitgeb wrote:
>> The redirection is always done with redirectXxx() methods of
>> ProcessBuilder.
> The only one I can see documented is redirectErrorStream() [...]

<http://docs.oracle.com/javase/7/docs/api/java/lang/ProcessBuilder.html#redirectOutput(java.lang.ProcessBuilder.Redirect)>

Maybe, you were using an old JavaDocs-bookmark?
(Google also sometimes links to older Javadocs)

These other redirectXxx() only came in 1.7 

[toc] | [prev] | [next] | [standalone]

#29844

On Sun, 24 Aug 2014 22:33:52 +0000, Andreas Leitgeb wrote:

> Martin Gregorie <martin@address-in-sig.invalid> wrote:
>> On Sun, 24 Aug 2014 13:41:18 +0000, Andreas Leitgeb wrote:
>>> The redirection is always done with redirectXxx() methods of
>>> ProcessBuilder.
>> The only one I can see documented is redirectErrorStream() [...]
> 
> <http://docs.oracle.com/javase/7/docs/api/java/lang/
ProcessBuilder.html#redirectOutput(java.lang.ProcessBuilder.Redirect)>
> 
> Maybe, you were using an old JavaDocs-bookmark?
> (Google also sometimes links to older Javadocs)
> 
> These other redirectXxx() only came in 1.7

Yep - looks like its time I upgraded docs and stuff: I'm currently in the 
middle of a C project but have some new Java stuff waiting in the wings.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#29813

On 08/22/2014 12:49 PM, Andreas Leitgeb wrote:
> I'm fully aware, that the concept of a mutable "current directory"
> for the whole VM does not work at all well with threads, and thus
> there is of course no such thing like "System.chDir(...)" in Java.
>
> Instead, I'd like to use a mutable Wrapper for java.nio.file.Path
> and whereever I need to access a file, I'd call a method on the
> wrapper and that would check, if the file's path is a relative
> or an absolute one, and eventually join it with the wrapped Path
> object. The wrapper itself then could offer something like a chDir()
> method to replace its wrapped Path by a target Path after following
> a series of ".."(for stepping up to the Parent-dir), or subfolders.
>
> e.g.: the wrapped Path of curDir originally points to "/tmp", then...
>   - curDir.chDir("foo") would go to "/tmp/foo", then
>   - curDir.chDir("../bar") would go to "/tmp/bar", then
>   - curDir.chDir("/foo") would go to "/foo"
> Whether it would check the file system about each of these
> paths, and whether it would resolve symlinks or just use them
> verbatim, is not among the things I care for at this point.
>
> With that, the concept of "current directory" would be tied to
> a particular "curDir" object, and the user would be responsible
> to either keep it to a single thread, or at least care about
> proper synchronisation across threads (as with all mutable objects).
>
> I had a look at the classes/interfaces in java.(n)io, but couldn't
> find such a class. Is it not there, or did I just miss it?

It seems to me that a "process" might have a notion of a
"current directory". And that a file system "traverser"
might have its notion of a "current directory". But any
set of classes implementing a "virtual file system" wouldn't
need the concept of a "current directory". May be that there
is better place to "home" the abstraction.

> While it wouldn't be too hard to implement it for a particular
> platform, getting it right for different platforms (maybe even
> platforms where absolute/relative paths follow different patterns)
> would be tricky enough, that I'd rather use a library classes (if
> one exists), than roll my own.
>
> PS: Java 7 here
>

[toc] | [prev] | [next] | [standalone]

#29824

Jeff Higgins <jeff@invalid.invalid> wrote:
> It seems to me that a "process" might have a notion of a
> "current directory". And that a file system "traverser"
> might have its notion of a "current directory". But any
> set of classes implementing a "virtual file system" wouldn't
> need the concept of a "current directory". May be that there
> is better place to "home" the abstraction.

I'm afraid, I don't quite get the point of this nor your
other two posts in this thread.

[toc] | [prev] | [next] | [standalone]

#29826

On 08/23/2014 11:32 AM, Andreas Leitgeb wrote:
> Jeff Higgins <jeff@invalid.invalid> wrote:

"I had a look at the classes/interfaces in java.(n)io, but couldn't
find such a class. Is it not there, or did I just miss it? "

>> It seems to me that a "process" might have a notion of a
>> "current directory". And that a file system "traverser"
>> might have its notion of a "current directory". But any
>> set of classes implementing a "virtual file system" wouldn't
>> need the concept of a "current directory". May be that there
>> is better place to "home" the abstraction.
>
> I'm afraid, I don't quite get the point of this nor your
> other two posts in this thread.
>

You snipped the paragraph to which I responded.

A class wrapping java.nio.file.Path, as you describe,
is an odd choice for placement of a method to change
a process' current working directory.

If you have a chdir, why not a chroot?
You may not need it, but if they were in a standard
library someone would.

Compare:
sun.nio.fs.AixFileSystem
sun.nio.fs.UnixFileSystem
sun.nio.fs.WindowsFileSystem

[toc] | [prev] | [next] | [standalone]

#29828

On 08/23/2014 11:32 AM, Andreas Leitgeb wrote:
> Jeff Higgins <jeff@invalid.invalid> wrote:
>> It seems to me that a "process" might have a notion of a
>> "current directory". And that a file system "traverser"
>> might have its notion of a "current directory". But any
>> set of classes implementing a "virtual file system" wouldn't
>> need the concept of a "current directory". May be that there
>> is better place to "home" the abstraction.
>
> I'm afraid, I don't quite get the point of this nor your
> other two posts in this thread.
>

Java Service Wrapper
<http://wrapper.tanukisoftware.com/>

Hint:
The source covers much of the ground
your recent posts suggest you are exploring.

[toc] | [prev] | [next] | [standalone]

#29816

Andreas Leitgeb schrieb:
> e.g.: the wrapped Path of curDir originally points to "/tmp", then...
>   - curDir.chDir("foo") would go to "/tmp/foo", then
>   - curDir.chDir("../bar") would go to "/tmp/bar", then
>   - curDir.chDir("/foo") would go to "/foo"

if you use a static variable to hold the current
directory, it will be seen class loader wide.

Means for a standalone application you will
have one current directory, and for web applications
it could happen that each web context has its own
current directory.

public class State {
     private static String curdir;

     public void chDir(String str) {
         curdir = new FIle(curdir,str).getCanonicalPath();
     }

}

The getCanonicalPath() method will usually resolve
../ and ./ parts in the str together with curdir.
But I am not sure how binding the Java contract is.
I find in the comment only saying "typical":

   "A canonical pathname is both absolute and unique.
    The precise definition of canonical form is system-
    dependent.  This method first converts this pathname
    to absolute form if necessary, as if by invoking the
    {@link #getAbsolutePath} method, and then maps it to
    its unique form in a system-dependent way.  This
    typically involves removing redundant names such as
    <tt>"."</tt> and <tt>".."</tt> from the pathname,
    resolving symbolic links (on UNIX platforms), and
    converting drive letters to a standard case (on
    Microsoft Windows platforms)."

Bye

[toc] | [prev] | [next] | [standalone]

#29817 — With new Path (Re: A "current directory" concept for Java...)

Jan Burse schrieb:
>
> The getCanonicalPath() method will usually resolve
> ../ and ./ parts in the str together with curdir.

Things are a little confusing under the hood of
java.io.File. Since they use a method named resolve
which does not resolve ../ and ./.

The same confusion is under the hood of java.nio.file.Path,
the method named resolve does also not resolve ../ and
./. Here you have to use the method normalize.

So the solution with path would be:

public class State {
     private static String curdir;

     public void chDir(String str) {
         curdir = Paths.getPath(curdir).resolve(str).normalize();
     }

}

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web