infinisil changed the topic of #nix-lang to: Channel for discussing Nix as a language - https://nixos.org/nix/manual/#chap-writing-nix-expressions - Logs: https://logs.nix.samueldr.com/nix-lang/
Dotz0cat has joined #nix-lang
Dotz0cat_ has quit [Ping timeout: 256 seconds]
rajivr has joined #nix-lang
blueberrypie has quit [Quit: leaving]
blueberrypie has joined #nix-lang
rajivr has quit [Quit: Connection closed for inactivity]
rajivr has joined #nix-lang
Dotz0cat_ has joined #nix-lang
Dotz0cat has quit [Ping timeout: 272 seconds]
pingiun has quit [Quit: Bye!]
pingiun has joined #nix-lang
__monty__ has joined #nix-lang
ris has quit [Ping timeout: 264 seconds]
ris has joined #nix-lang
ris has quit [Ping timeout: 260 seconds]
ris has joined #nix-lang
pie_ has joined #nix-lang
rajivr has quit [Quit: Connection closed for inactivity]
mcint has joined #nix-lang
<ehmry> does anyone know where `opening file '//builtin/derivation.nix': No such file or directory` comes from?
<ehmry> I've seen it before, but I cannot remember why
<infinisil> ehmry: It's in the nix source :)
<ehmry> right, but there is some condition that causes this, like a missing argument to derivation
__monty__ has quit [Quit: leaving]
<sterni> TIL: nix strings are not a byte array
<sterni> the may _not_ contain any NUL bytes
<sterni> although I wonder if there is a way to cheese some into it
<sterni> I tried builtins.readFile and string literals, both don't work
<sterni> string literals which contain actual NUL bytes lead to the nix parser just treating the NUL byte as EOF as far as I can tell
<sterni> and reading a file that has a NUL byte in it leads to
<sterni> error: the contents of the file '/home/lukas/src/depot/test.txt' cannot be represented as a Nix string
<ekleog> interesting, getEnv apparently escapes the null byte before putting it in a string
<sterni> ekleog: it just treats it as end of string which is roughly the same behavior as if it is in a string literal
<ekleog> Hmmmmmm?
<ekleog> $ export TEST="aa\0aa"
<ekleog> $ xxd <(echo $TEST) ~
<ekleog> 00000000: 6161 0061 610a aa.aa.
<ekleog> $ nix repl
<ekleog> nix-repl> builtins.getEnv "TEST"
<ekleog> "aa\\0aa"
<sterni> ohhhhh
<sterni> seems like fish did something to the NUL byte
<sterni> this is incredible
<ekleog> yeah I'm like how does it reach this result too ^^'
<ekleog> but well time to sleep here so I'll leave you with that, sorry :)
<sterni> ekleog: in your example, bash does the escaping actually
<sterni> or is that not bash?
<sterni> huh
<sterni> sleep tight either way :)
<mcint> in bash, you would need `echo -e` to interpret the expression
<ekleog> hmm I think the `xxd <(echo $TEST)` properly validated that the variable is not already the escaped version of it?
<ekleog> (I'm using zsh, fwiw)
<ekleog> hmmmmmm interesting, using `export TEST="$(echo -e 'aa\0aa')"` leads to the same result with `xxd` but to `"aa"` with nix repl, so it was probably a problem of checking with xxd, though I'm far from sure how it could lead to this result
<sterni> ekleog: try using printf '%s' "$TEST" instead of echo
<ekleog> $ xxd <(printf '%s' "$TEST") ~
<ekleog> 00000000: 6161 0061 61 aa.aa
<ekleog> oh wait that was with the wrong $TEST, with the `export TEST="aa\0aa"` one it does output 00000000: 6161 5c30 6161 aa\0aa
<sterni> $ export TEST="$(printf '\0')"
<sterni> bash: warning: command substitution: ignored null byte in input
<ekleog> that's iiinteresting, I was convinced that without -e echo wouldn't interpret the escapes, but it sounds like not
<ekleog> welp sounds like shells are as broken as nix in that regard I guess? :p
<sterni> in fish the NUL byte is just skipped
<sterni> yeah NUL bytes are dangerous business I think it's obvious why shells would stay clear of it
<sterni> maybe even something about that in POSIX
<sterni> but in nix it feels really weird tbh
<sterni> probably somewhere there is a C string in the implementation which prompted all of this :p