10
\$\begingroup\$

At times, it may be advantageous for a solution to a challenge to make certain assumptions about, for example, the directory from which it is run. For example, a bash script that compiles and runs a file with gcc can reduce

./a.out

to

./a*

if it can safely assume that no other files in the present working directory have a name that begins with a.

Should this be allowed? What about assumptions about the file name of the code being run? We already have a policy that adds the length of the file name to the score if it has to have a certain name (informal? I can't find a definitive statement of this policy), but what if the file name simply can't be a certain string (for example, the bash script above would have to have a name that doesn't start with a)?

Another interesting conundrum is tricks like /d*/u*m instead of /dev/urandom. On my system, /dev/urandom is the only file that matches the glob, but this may not be the case on others.

How should these cases be handled?

(note that my self-answers are intended as proposals and not declarations; treat them in the same manner as you would if they were posted by any other user.)

\$\endgroup\$

3 Answers 3

Reset to default
13
\$\begingroup\$

Assumptions about the working directory

The present working directory may be assumed to be empty. If the program is run from a file, the present working directory may alternatively be assumed to be empty except for the file being run.

However, nothing may be assumed about the full path to the present working directory except that it is a legal path name on the system in question. (That is, solutions must handle cases where the path to the present working directory contains spaces, for example.)

If a submission requires an extra file in the present working directory, it should be counted according to our existing policy for multi-file submissions.

\$\endgroup\$
2
  • \$\begingroup\$ "solutions must handle cases where the path to the present working directory contains spaces" — I'm not sure about this requirement, and I think there are several existing answers where this isn't the case (first example I found via Google is codegolf.stackexchange.com/a/104930/8927). In the same vein as basic ASCII being an acceptable assumption for text entry (i.e. unicode not required by default), I'd say [a-zA-Z0-9_/]+ is an acceptable assumption for file paths, unless otherwise stated. \$\endgroup\$
    – Dave
    Jun 12, 2017 at 21:08
  • \$\begingroup\$ Must programs assume a case sensitive or non case sensitive file system, or should they work on both \$\endgroup\$
    – Ferrybig
    Jun 13, 2017 at 19:49
11
\$\begingroup\$

Assumptions about the file name

To restate a policy that I thought we had but can't actually find a source for: If the submission is required to have a certain file name, the length of the file name must be added to the submission's score.

If the submission fails for any legal file name, it must specify a file name to be used and count this name in the score. (This does not apply to submissions that can be run by providing the code itself as a command line argument, of course.) This is the only way I can think of to prevent abuse of the rules such as "this works for an infinite number of file names, but it has to start with Hello, World!."

To put it another way, a file name (this applies for every file name in multi-file submissions) can only not be counted in the score when the file name is wholly immaterial to the functionality of the submission and only affects the invocation of the submission. This is consistent with our existing policy for multi-file submissions.

\$\endgroup\$
5
  • 1
    \$\begingroup\$ The only "problem" I can think of is a unicode file name, since it's legal (at least on windows), but there are languages that don't have unicode support. \$\endgroup\$
    – Conor O'Brien
    Jun 10, 2017 at 18:05
  • \$\begingroup\$ @ConorO'Brien Can you give an example for a language that has problems with unicode filenames (with an otherwise normal source like Hello World)? \$\endgroup\$
    – L3viathan
    Jun 10, 2017 at 18:23
  • 4
    \$\begingroup\$ @L3viathan C in my own terminal, but it works fine on TIO. Largely, anything written in a language without unicode support \$\endgroup\$
    – Conor O'Brien
    Jun 10, 2017 at 19:05
  • \$\begingroup\$ @ConorO'Brien I don't think that "ASCII-only filename" is a restriction that would run afoul of this rule. You're not storing information in the filename - you're just dealing with a restriction of the language. Similarly, if restrictions are imposed by the language and not the specific program (like requiring a certain file extension), that shouldn't be counted against the program. \$\endgroup\$
    – user45941
    Jun 11, 2017 at 5:28
  • \$\begingroup\$ @Mego I think that's perfect. I wasn't sure to what extent "legal" meant. \$\endgroup\$
    – Conor O'Brien
    Jun 11, 2017 at 5:47
0
\$\begingroup\$

Quinelike things can't store info in the file name

you may not print(filename) etc.

\$\endgroup\$
3
  • 1
    \$\begingroup\$ IMO this is covered by this and this \$\endgroup\$
    – user45941
    Jun 11, 2017 at 5:25
  • \$\begingroup\$ just covering up doorknobs answer about file name \$\endgroup\$
    – Destructible Lemon
    Jun 11, 2017 at 7:32
  • \$\begingroup\$ I don't think this answer is relevant \$\endgroup\$
    – mbomb007
    Jun 19, 2017 at 16:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .