denoland
thread 'main' panicked - Deno doesn't like emojis in path, maybe?
I have emojis in my paths, and it looks like Deno isn't fond of that?
$ bin/build
============================================================
Deno has panicked. This is a bug in Deno. Please report this
at https://github.com/denoland/deno/issues/new.
If you can reliably reproduce this panic, include the
reproduction steps and re-run with the RUST_BACKTRACE=1 env
var set and include the backtrace in your report.
Platform: macos aarch64
Version: 2.1.9
Args: ["deno", "run", "-A", "bin/build"]
thread 'main' panicked at std/src/env.rs:163:83:
called `Result::unwrap()` on an `Err` value: "$HOME/project/\xF0\x83\xBF\xA7\x83\x80 foo/\xF0\x83\xBF\x83\xB3\x83\xA8 bar/baz/bin/build"
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
The bin/build script:
#!/usr/bin/env -S deno run -A
import * as esbuild from "npm:[email protected]";
import { denoPlugins } from "jsr:@duesabati/esbuild-deno-plugin@^0.0.1";
const result = await esbuild.build({
plugins: [...denoPlugins()],
entryPoints: ["https://deno.land/[email protected]/bytes/mod.ts"],
outfile: "./dist/bytes.esm.js",
bundle: true,
format: "esm",
});
console.log(result.outputFiles);
esbuild.stop();
Oh whoops, yes I thought I had done so. Also note below failure is only when invoked via shebang:
$ export RUST_BACKTRACE=1
$ la foo.ts
Permissions Size User Date Modified Name
.rwxr-xr-x@ 414 gaggle 28 May 14:23 foo.ts
$ cat foo.ts
#!/usr/bin/env -S deno run -A
import * as esbuild from "npm:[email protected]";
import { denoPlugins } from "jsr:@duesabati/esbuild-deno-plugin@^0.0.1";
const result = await esbuild.build({
plugins: [...denoPlugins()],
entryPoints: ["https://deno.land/[email protected]/bytes/mod.ts"],
outfile: "./dist/bytes.esm.js",
bundle: true,
format: "esm",
});
console.log(result.outputFiles);
esbuild.stop();%
$ deno run -A foo.ts
undefined
$ ./foo.ts
============================================================
Deno has panicked. This is a bug in Deno. Please report this
at https://github.com/denoland/deno/issues/new.
If you can reliably reproduce this panic, include the
reproduction steps and re-run with the RUST_BACKTRACE=1 env
var set and include the backtrace in your report.
Platform: macos aarch64
Version: 2.1.9
Args: ["deno", "run", "-A", "./foo.ts"]
thread 'main' panicked at std/src/env.rs:163:83:
called `Result::unwrap()` on an `Err` value: "$HOME/foo/\xF0\x83\xBF\xA7\x83\x80 bar/\xF0\x83\xBF\x83\xB3\x83\xA8 baz/ham/./foo.ts"
stack backtrace:
0: _rust_begin_unwind
1: core::panicking::panic_fmt
2: core::result::unwrap_failed
3: <std::env::Vars as core::iter::traits::iterator::Iterator>::next
4: deno_os::op_env::op_env::slow_function_impl
5: deno_os::op_env::op_env::v8_fn_ptr
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
$ export RUST_BACKTRACE=full
$ ./foo.ts
============================================================
Deno has panicked. This is a bug in Deno. Please report this
at https://github.com/denoland/deno/issues/new.
If you can reliably reproduce this panic, include the
reproduction steps and re-run with the RUST_BACKTRACE=1 env
var set and include the backtrace in your report.
Platform: macos aarch64
Version: 2.1.9
Args: ["deno", "run", "-A", "./foo.ts"]
thread 'main' panicked at std/src/env.rs:163:83:
called `Result::unwrap()` on an `Err` value: "$HOME/foo/\xF0\x83\xBF\xA7\x83\x80 bar/\xF0\x83\xBF\x83\xB3\x83\xA8 baz/ham/./foo.ts"
stack backtrace:
0: 0x1017c4ee4 - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::habbf9c4f641febb1
1: 0x100a8a55c - core::fmt::write::ha36a8060c13608ea
2: 0x1017941e4 - std::io::Write::write_fmt::h431832c8ebcc85c9
3: 0x1017c7248 - std::panicking::default_hook::{{closure}}::h4aa1f60327dfff6a
4: 0x1017c6e8c - std::panicking::default_hook::h4ebc6eb4ae179807
5: 0x100a054f0 - deno::setup_panic_hook::{{closure}}::hb268a096200b2479
6: 0x1017c8148 - std::panicking::rust_panic_with_hook::h6a84efe4dcab239c
7: 0x1017c7ba8 - std::panicking::begin_panic_handler::{{closure}}::h5eef292190467fef
8: 0x1017c7b1c - std::sys::backtrace::__rust_end_short_backtrace::hd7e7925203f20af9
9: 0x1017c7b10 - _rust_begin_unwind
10: 0x100a88d78 - core::panicking::panic_fmt::h410d3f147658259b
11: 0x100a8f43c - core::result::unwrap_failed::h974e6b19638d9dc8
12: 0x1017b6d94 - <std::env::Vars as core::iter::traits::iterator::Iterator>::next::h6970a2ae44af9844
13: 0x1010dfb20 - deno_os::op_env::op_env::slow_function_impl::hf9ba754e6ae0ab10
14: 0x1010df92c - deno_os::op_env::op_env::v8_fn_ptr::h329a3bc53483841b
$ pwd
$HOME/foo/🧠 bar/📈 baz/han
Thanks for providing the backtrace - we are hitting the panic described here: https://doc.rust-lang.org/std/env/fn.vars.html#panics - since one of the env vars is not a valid unicode the function panics. In op_env we should use std::env::vars_os() and manually iterate and decode vars - either silently ignoring ones that are invalid or returning an actual error.
What text encoding is your environment using? Looking at the values in the error message \xF0\x83\xBF\x83\xB3\x83\xA8 isn't valid in any encoding I can identify. So either your encoding is very exotic, or something is garbling those values along the way.
I can't reproduce this issue on my machine (macos) so there must be something different about your environment, but it's hard to tell what
Oh. Just normal macOS zsh, running Warp terminal. I’m not aware of any unusual settings, sorry.
The package manager is pkgx, installed via homebrew.
Maybe this is just a wild goose chase.