Deno: "deno https://deno.land/welcome.ts" should work

[ry]

Somehow we should be able to examine the arguments - maybe by trying to parse a URL - and default to run.

That is "deno -A https://deno.land/welcome.ts" maps to "deno run -A https://deno.land/welcome.ts"

[bartlomieju]

So you want deno without subcommand to behave exactly like deno run? If so that's pretty easy to achieve, I can raise a PR from previous commits.

[hayd]

An alternative is to output that as a suggestion... Or a warning to stderr to prefer use of explicit run command.

[kitsonk]

Personally from an ergonomic perspective, if you can analysis and output a suggestion, just f*ing run the code. I really have disliked the need for run though I understand the need. Anything that simplifies it I am for.

[MarkTiedemann]

I really have disliked the need for run though I understand the need.

What is the need for run? Is it to prevent ambiguity? e.g. an info file colliding with the info subcommand?

I was under the impression that Deno scripts, in contrast to Node scripts, should have an extension (e.g. .ts).

So this is only relevant for usage in executable scripts with shebangs, right? e.g.

// ./info
#!/usr/bin/env deno run
console.log("Important info!")

$ chmod +x info
$ ./info
Important info!

Note that shebang-usage as shown above won't work on Linux since it treats the shebang args as a single argument (e.g. 'deno run': No such file or directory).

Note that this also won't work on Windows since there are no shebangs. However, you can use file associations on Windows to easily turn your Deno scripts into executable files, e.g.

setx PATHEXT %PATHEXT%;.ts
assoc .ts=deno
ftype deno=deno.exe run %1 %*

// C:\deno\hello.ts
console.log("Hello World!")

C:\deno> hello
Hello World!

So, unless I'm missing something, only on Linux this would lead to issues when using an executable script named just like a Deno subcommand. To me, that doesn't justify making Deno usage less ergonomic for Mac and Windows users. I'd rather see a note in the documentation that says that you shouldn't name your Deno executable script on Linux like a Deno subcommand because, if you do, the subcommand will be executed rather than your script...

[bartlomieju]

We added deno run to simplify CLI arg parsing... But I agree that it is less ergonomic.

After some thought I believe we can bring back deno <script> syntax. If one wants to run REPL with some args then using deno -- --foo --bar can be used.

So:

$ deno // run REPL
$ deno -- --foo --bar // run REPL (Deno.args === ["--", "--foo", "--bar"]
$ deno script.ts // run script.ts
$ deno --allow-net // run script.ts with net perm

I'll put up PR with this change in the evening for further discussion.

[MarkTiedemann]

If one wants to run REPL with some args then using deno -- --foo --bar can be used.

How about a repl subcommand, e.g. deno repl --foo instead of deno -- --foo?

$ deno             # short for `deno repl`
$ deno repl        # run REPL
$ deno repl --foo  # run REPL with args

$ deno script.ts      # short for `deno run script.ts`
$ deno run script.ts  # run script.ts

[bartlomieju]

We can close this issue now