Busy porting FPCUP to Linux... think it's time to quit for the day....

This code:
OperationSucceeded:=ForceDirectories(BootstrapCompilerDirectory);
debugln('todo: debug: forcedirectories bootstrap compiler dir:
'+bootstrapcompilerdirectory+' result: '+BoolToStr(Operationsucceeded));

should create a directory (~/fpcbootstrap by default): The output that debugln produces:
Debug: todo: debug: forcedirectories bootstrap compiler dir: ~/fpcbootstrap/ result: -1

Result=-1, so that's true & it must have worked, right?

No, the directory is not created:
ls ~/fpcbootstrap
ls: cannot access /home/pascaldev/fpcbootstrap: No such file or directory

What am I doing wrong?
Should I spell out the entire path /home/pascaldev/fpcbootstrap/? Leave the trailing slash?

Thanks for any tips,
Reinier

On Mon, Feb 6, 2012 at 18:40, Reinier Olislagers <

You should use ExpandFileName on ForceDirectory's content prior on sending it to it.

Your shell expands ~ to your home directory. Your program will have to do this manually (i.e. read the "HOME" environment variable).

Henry

Thanks Ido,
Reinier

Henry Vermaak wrote

Your shell expands ~ to your home directory. Your program will have to do this manually (i.e. read the "HOME" environment variable).

Like Ido mentioned, ExpandFileName does this already. Perhaps the documentation could mention it.

Henry

<snip>

I understand. Apparently ExpandFileName does this for me.

Still, I don't understand why I got a result that was true when FPC apparent!??!.... Oh now I do, it created the directory "~\fpcbootstrap". That was fun ;)

Perhaps I should submit a patch for the docs indicating that:
- ForceDirectories requires an absolute path
- On Unix/Linux, directories starting with ~ are considered relative (but where should that be put...)

Suggestions welcome.

In any case, glad this works, thanks for the help!

Reinier

Tried to add some remarks using fpdoc editor. svn diff gave a huge list of changes against svn...
ForceDirectories: description
<p>
Note: this function only accepts absolute directories. E.g. on Unix, directories starting with ~ or .. need to be expanded to absolute directories first (e.g. using
<link id="ExpandFileName"/>)</p>

ExpandFileName: description
<p>
On Unix/Linux systems, this will also expand directories with ~ (the home directory) to the full, absolute path.</p>

Giving up for now...

Thanks for all the help,
Reinier

ik wrote

You should use ExpandFileName on ForceDirectory's content prior on sending it to it.

And then go find the directory that you created in error and remove it! ;)

Rich

Thanks, Rich, did that ;)

Task for tomorrow is to find out how to do chmod u+x someexecutable, but that's for tomorrow - right now I'm liable to start throwing keyboards through the window or falling asleep ;)

Regards,
Reinier

The documentation is your friend:
http://www.freepascal.org/docs-html/rtl/baseunix/fpchmod.html

Regards,
Sven

This is wrong. ForceDirectories works with relative paths as well. It just does not work with path variables that are only known to the shell.

- On Unix/Linux, directories starting with ~ are considered relative (but where should that be put...)

This is basic Linux/Unix knowledge: every path that does not start with a "/" is a relative path.

Regards,
Sven

[...] - On Unix/Linux, directories starting with ~ are considered relative (but where should that be put...)

Only in shells the tilde has the special meaning. Linux (the kernel) does not treat tilde special.

Mattias

Mmmm, must have been my tiredness. Yes, I know ~ is not an absolute path. I supposed ForceDirectories' failure to expand ~ meant it could not deal with absolute paths. Too tired to investigate further.

And while ~ is a relative path, the defining characteristic is that is a character that gets expanded by (at least) the shell, as Mattias pointed out in his other mail.

Still, ExpandFileName DOES expand ~ to /home/whatever, and that is not mentioned in help:
"ExpandFileName expands the filename to an absolute filename."

I think the docs for ExpandFileName should be updated to indicate ~ gets expanded, e.g.:
"ExpandFileName expands the filename to an absolute filename. On Unix/Linux systems, ExpandFileName will also expand the ~ (home directory) symbol."

Thanks,
Reinier

Thanks Sven, strange as it may seem, I did start with the documentation today - but ended up in the oldlinux unit, so thanks for the link ;)

It even works ;)

And while ~ is a relative path,

No, this is an absolute path (pointing to the home directory). It only needs expansion to give you this absolute path. It's just a placeholder for a certain absolute path (which can vary). One or two dots would be a relative path (meaning current and parent directory).

the defining characteristic is that is a character that gets expanded by (at least) the shell, as Mattias pointed out in his other mail.

And it's not the only variable that can be expanded (by the shell). Environment variables may be used in paths too.

Still, ExpandFileName DOES expand ~ to /home/whatever, and that is not mentioned in help: "ExpandFileName expands the filename to an absolute filename."

How can this be misunderstood? What else should be expanded if not placeholders and variables?

But ~ is not the only placeholder that will be expanded. Relative paths would become absolute paths and environment variables will be replaced by their values too. And I think it's not restricted to Linus/Unix, it happens on Windows too. So if at all I would list all these possible expansions:

"ExpandFileName expands the filename to an absolute filename. Replaced would be
-) placeholders (like ~)
-) environment variables (like HOME)
-) relative path would completed to absolute paths etc.

That's fine. If you just say "anything gets expanded to an absolute path", in my mind:
1. you're implying the thing you're expanding is relative (even if you're not saying so)
2. you're leaving users to guess what "expanded" means exactly. From relative to absolute? What placeholders get "expanded", if any, etc.

Might be that I'm just too stupid sometimes, but if we can help the stupid users too, why not ;)

Sounds like a good suggestion, Jürgen!

Regards,
Reinier

I will look into improving the documentation. The implementation has been improved over the years.

Michael.

Until Michael updates the documentation, some comments from me:

1) "~" is the only placeholder which is expanded by ExpandFileName and this only on Unix platforms (in particular, those containing {$DEFINE FPC_FEXPAND_TILDE} in the respective parts of implementations of units sysutils (and dos for FExpand).

2) No environment variables are expanded by ExpandFileName; the "~" placeholder is directly replaced by content of environment variable HOME as appropriate, but if you include $HOME (or %HOME% under Dos / OS/2 / Windows), it will stay in the expanded value literally. Changing this would result in an incompatibility to Delphi and TP/BP. Should an environment variable expansion feature be required, I'd do it by adding a new function or an overloaded variant to the RTL (we could still share the same implementation code, but probably add a different compiler define).

3) The ExpandFileName / FExpand implementation is shared across all supported targets, but the set of features used for a particular target is determined by conditional defines within the particular RTL version - see comments at the end of rtl/inc/fexpand.inc for details. This means that the exact behaviour tries to accomodate standard filesystem API conventions and features relevant for the different targets.

Tomas

That's fine. If you just say "anything gets expanded to an absolute path", in my mind: 1. you're implying the thing you're expanding is relative (even if you're not saying so)

No, IMO this is not true. A relative path is relative to the current directory (or some other directory). This is not the case for ~. It is not relative to any other directory (it is not appended to another path). It stands for an absolute path on its own.

2. you're leaving users to guess what "expanded" means exactly. From relative to absolute? What placeholders get "expanded", if any, etc.

True. It is assumed that users know about relative and absolute paths and existing placeholders. Of course, there is no harm to add more explanations but someone has to do so and time is limited.

Might be that I'm just too stupid sometimes, but if we can help the stupid users too, why not ;)

Agree. Too much information is better then too little information. Assumption are often wrong. I was expecting environment variables too be expanded but it seems they are not ;-)

Yes, it IS true ;) I'm talking about what it implies to ME (and possibly other people)... Fortunately below we agree on assumptions ;)

Agreed about resources. Might help if fpdoc and/or lazde did not totally screw up the XML so sending a diff is impossible.
Ah well... No sense beating dead horses/going over things that already have been discussed in the list.

ACK ;)