Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should the way to set tmpdir from the environment be known to the user? #5933

Open
p6rt opened this issue Dec 31, 2016 · 1 comment
Open

Comments

@p6rt
Copy link

p6rt commented Dec 31, 2016

Migrated from rt.perl.org#130464 (status was 'new')

Searchable as RT130464$

@p6rt
Copy link
Author

p6rt commented Dec 31, 2016

From @briandfoy

I was looking at how tmpdir does its work so I can explain what people
need to do in order for it to do its work. All of the current IO​::Spec modules
currently inherit from IO​::Spec​::Unix, and it looks like these three have
the same tmpdir code that differs only by the list of directories to try​:

  IO​::Spec​::Unix
  %*ENV<TMPDIR>,
  '/tmp',

  IO​::Spec​::Win32 (is IO​::Spec​::Unix)
  $ENV<TMPDIR>,
  $ENV<TEMP>,
  $ENV<TMP>,
  'SYS​:/temp',
  'C​:\system\temp',
  'C​:/temp',
  '/tmp',
  '/',

  IO​::Spec​::Cygwin (is IO​::Spec​::Unix)
  %ENV<TMPDIR>,
  "/tmp",
  %ENV<TMP>,
  %ENV<TEMP>,
  'C​:/temp',

I have a couple of questions about that.

0. I mostly want to be able to say "Set FOO to set the temporary
directory" and have that be a solid commitment from Perl 6. The docs
for $*TMPDIR and tmpdir do not document how they decide what value to
have.

1. Aside for platform specific expectations, should tmpdir look at
environment variables in the same order? Notice that in Cygwin, '/tmp'
shows up in the middle (right after TMPDIR, like in Unix), but it
would also look in other environment variables. I tend to think that
if an environment variable is set, it should come before a hard-coded
solution. Notice also that Win32 and Cygwin check TMP and TEMP in
different orders. I saw on MSDN (from Raymond Chen, no less) that
Windows's GetTempFileName looks at TMP first and then TEMP, but I
don't think that matters much and most systems seem to set both to the
same value.
(https://blogs.msdn.microsoft.com/oldnewthing/20150417-00/?p=44213)

2. As a matter of code duplication, is there some issue or future work
that precludes having the derived classes define a directory order
while leaving tmpdir in the base class (IO​::Spec​::Unix)? The thing
that I would think might kill that is platform-specific filesystem
checks (ACLs? whatever NTFS does? etc) that are not be handled by the
unixy file test methods.

  method temp-dirs-to-try { ... } # in each base class

  method tmpdir { # only in the base class
  my $ENV := %*ENV;
  my $io;
  first( {
  if .defined {
  $io = .IO;
  $io.d && $io.r && $io.w && $io.x;
  }
  },
  self.temp-dirs-to-try
  ) ?? $io !! IO​::Path.new(".");
  }

3. Whatever those answers are, do we guarantee to a Perl 6 user a
particular way to set the value. For instance, someone writes a
portable program and tells their users to set TMP because that is what
works for them and they don't know about other options. But, someone
runs it on a Unixy place and they use TMP because the instructions say
to use that. I suppose this comes down to how much of the underlying
system and practice do you let leak through and your tolerance for "On
Unix set FOO, on Windows set BAR". That answer might be to tell
everyone that TMPDIR will always be checked first. But, also possibly
let users set all the same variables in each environment.

4. Or, it just doesn't matter because you should care where the
temporary files are.

5. Except, if none of the locations work, the temp files end up in the
current working directory (and is it odd to get that by
IO​::Path.new(".") instead of $*CWD?), which might not have the
attributes required of the other candidates (that is, is writeable)?
That blows up potentially far away from the place that set it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant