#541 astyle not finding project's .astylerc file.

[Oscar Kramer]

Running

astyle -v --project

Is not finding the options file in the CWD, and getting error: "Cannot open project option file .astyle"

To reproduce, cd into working directory containing .astylerc. and run above command line.

Discovered that
ASConsole::findProjectOptionFilePath(const string& fileName_) const
was incorrectly stripping the CWD name from the full path because it was missing the trailing '/'. Specifically, in the block under "// remove filename from path," it was removing the current working directory name from the path because it didn't end with '/', and filepath ended up with the parent of the CWD. I modified as follows for it to work (around line 685 of astyle_main.cpp:

...
    else
   {
      parent = getFullPathName(getCurrentDirectory(fileName_));
      parent += "/";
   }
...

[Frederik Schaff]

I also encountered this bug today when using astyle from git-bash (Mingw) in a pre-commit hook. The problem seems to be related to the way astyle searches for the .astylerc file, disregarding the --option= flag. It tried to use a folder C:\Users\USERNAME\AppData\Roaming\astylerc\. When I deleted this folder, it picked up the correct file provided as option.

I think it is unreliable that the explicit option can be silently overwritten by an implicit search path (?), which is highlighted by this bug. The documentation mentions that

The project option file has precedence over the default option file.

Even if it is not silently using another file, the question is why does it search for a default file and fail if it cannot open it DESPITE an alternative has been provided explicitly.

But this seems not to be the case. I can reproduce this issue with MINGW and Ubuntu@wsl2 via creating the problematic file path and then trying to run astyle, so it seems to effect the windows and linux implementation. The error information I get from MinGW (using windows astyle) actually provided the relvant hint. With Ubuntu@wsl2 I only got the information that the provided project file cannot be opened.

[satok]

On Windows, astyle --project=.astylerc src\foo.c
I got an error "Cannot open project option file"
even though .astylerc exists in the parent directory of the source file.

isHomeOrInvalidAbsPath() definitions in astyle_main.cpp:

if (absPath.compare(0, strlen(env), env) != 0)
    return true;

Here doing string_starts_with, I think != should be ==.

[André Simon]

confirmed and fixed Linux search

[John McCabe]

Can you tell me where this is fixed? Is it in the beta file download? I'm interested as I'm seeing this on Linux in the 3.2 beta code I've just downloaded and built.

[André Simon]

Hi, I will check it on Windows first and then prepare a new tarball.

[André Simon]

You can try today's second beta release (astyle-3.2-beta2).

[Max Schillinger]

Still broken?

I have just tested version 3.2-beta2 (on Linux). Now it works partially:

$ astyle --version
Artistic Style Version 3.2 beta

$ cat .astylerc
--indent=tab=4
--style=webkit
--indent-preproc-block
--align-pointer=type

$ astyle --project < src/parser/parser.c > src/parser/parser_astyle.c

$ astyle --project src/parser/parser.c
Cannot open project option file .astylerc
Artistic Style has terminated

$ astyle --project=.astylerc src/parser/parser.c
Cannot open project option file .astylerc
Artistic Style has terminated

Or is something wrong with my commands?

[Max Schillinger]

Bug fix:

Index: src/astyle_main.cpp
===================================================================
--- src/astyle_main.cpp (revision 679)
+++ src/astyle_main.cpp (working copy)
@@ -1188,7 +1188,7 @@
        if (absPath.c_str() == env)
                return true;

-       if (absPath.compare(0, strlen(env), env) != 0)
+       if (absPath.compare(0, strlen(env), env) == 0)
                return true;

        return false;
@@ -1477,7 +1477,7 @@
        if (absPath.c_str() == env)
                return true;

-       if (absPath.compare(0, strlen(env), env) != 0)
+       if (absPath.compare(0, strlen(env), env) == 0)
                return true;

        return false;

[Max Schillinger]

Just out of interest:
Is there any advantage in using

if (absPath.compare(0, strlen(env), env) == 0)

instead of

if (absPath.compare(env) == 0)

when you compare the whole strings anyway?

[Max Schillinger]

Oh sorry, my bug fix is exactly what @satok had suggested before. I guess I have cloned the wrong repo/branch/whatever. I'm not used to SVN.
I have checked again the code of the beta2 tarball. It looks like this bug was fixed for Windows but not yet for Linux.

[André Simon]

You may test again the 3.2-beta3 release, it should now work as expected.

[Max Schillinger]

I somehow missed this. It works! Thank you.