--project=. no longer works, and gives fatal error because of ENOENT. Why?

General Usage
1 
$ ~/.julia/environments/v1.11/.CondaPkg/env/bin$ pwd
/home/pharaldsson/.julia/environments/v1.11/.CondaPkg/env/bin

there pwd works but not here:

$ julia +1.11.1

julia> pwd()
ERROR: IOError: pwd(): no such file or directory (ENOENT)

That’s the first strange thing, and I’m not sure why… ENOENT.

Could be a bug? At least this separately?:

$ julia +1.11.1 --project=.
fatal: error thrown and no exception handler available.
InitError(mod=:Base, error=Base.IOError(msg="pwd(): no such file or directory (ENOENT)", code=-2))
uv_error at ./libuv.jl:106 [inlined]
pwd at ./file.jl:63
abspath at ./path.jl:450
init_active_project at ./initdefs.jl:258
__init__ at ./Base.jl:603
jfptr___init___74671.1 at /home/pharaldsson/.julia/juliaup/julia-1.11.1+0.x64.linux.gnu/lib/julia/sys.so (unknown line)
jl_apply at /cache/build/builder-demeter6-6/julialang/julia-master/src/julia.h:2157 [inlined]
jl_module_run_initializer at /cache/build/builder-demeter6-6/julialang/julia-master/src/toplevel.c:76
_finish_julia_init at /cache/build/builder-demeter6-6/julialang/julia-master/src/init.c:902
julia_init at /cache/build/builder-demeter6-6/julialang/julia-master/src/init.c:843
jl_repl_entrypoint at /cache/build/builder-demeter6-6/julialang/julia-master/src/jlapi.c:1053
main at /cache/build/builder-demeter6-6/julialang/julia-master/cli/loader_exe.c:58
unknown function (ip: 0x7fc87187fd8f)
__libc_start_main at /lib/x86_64-linux-gnu/libc.so.6 (unknown line)
unknown function (ip: 0x4010b8)

It’s the same in 1.10.5. File a bug (for the latter)? I at least want to know what might cause this. Maybe Julia needs not tolerate it (though better, in case people might blame Julia, unfairly?).

function pwd()
    buf = Base.StringVector(AVG_PATH - 1) # space for null-terminator implied by StringVector
    sz = RefValue{Csize_t}(length(buf) + 1) # total buffer size including null
    while true
        rc = ccall(:uv_cwd, Cint, (Ptr{UInt8}, Ptr{Csize_t}), buf, sz)
        if rc == 0
            resize!(buf, sz[])
            return String(buf)
        elseif rc == Base.UV_ENOBUFS
            resize!(buf, sz[] - 1) # space for null-terminator implied by StringVector
        else
            uv_error("pwd()", rc)
        end
    end
end

Am I hitting uv_error there? I’m actually looking into libUV a lot now, optimizing Julia’s println (with some success already), StaticCompiler.jl allows no allocations for printing, bypasses libUV I believe. I believe my Julia is unchanged, alll changes temporary in the REPL. Also I was getting some current directory warnings before my libUV investigations for a while, that I ignored…

Could my file-system be failing strangely?

This all works in my home directory, and I did:

$ ~/.julia/environments/v1.11/.CondaPkg/env/bin$ cd

$ julia +1.11.1 --project=.

[success]

$ cd -
bash: cd: /home/pharaldsson/.julia/environments/v1.11/.CondaPkg/env/bin: No such file or directory


usually gets me back to former directory. I think it simply was deleted in the meantime, by something I did, I can go to its parent, and start julia both ways there.
2

I think you simply deleted the directory where you are. At least the following reproduces the error you got:

% dir=$(mktemp -d)
% cd "${dir}"    
% rm -rf "${dir}"
% julia --project=.
fatal: error thrown and no exception handler available.
InitError(mod=:Base, error=Base.IOError(msg="pwd(): no such file or directory (ENOENT)", code=-2))
3

Yes, pwd from the shell just threw my off. It seems to cache intentionally?). I doubt Julia should do that (or the shell?), I’m using fish recently, not sure if I was then or bash.

Even if “self-inflicted” in a way, file a bug? There’s not a lot Julia can do when . (current dir is absent), Fall back to global env (likely worse), or just show less scary error… (without “unknown function (ip”?) similar to pwd() in REPL?

4

A bug about what?

5

“issue”. Bug is a bit misleading yes, Julia has few good options, though more “friendly” error message (I was editing, while you answered, there clarifying, “unknown”).

6

But what’s the issue?

7

abspath is maybe broken (in general) when current directly is unavailable. But it could still work with e.g. … or …/… hypothetically. When there’s no good way out, maybe thow an error (I think already done in pwd it uses) but then catch it in init_active_project and show an improved error?