@Zanna I'd guess that path lookups in hashbangs wasn't one of the original design purposes of env. But the design of some env implementations is influenced by this usage, offering an -S option where env -S... has the same effect as if the operand ... were split into possible multiple arguments that are themselves passed to env.

ek@Cord:~$ echo '#!/usr/bin/env -Sprintf [%s]\n first second third' >envtest
ek@Cord:~$ chmod +x envtest
ek@Cord:~$ ./envtest
[first]
[second]
[third]
[./envtest]

Though rather than using this hashbang:

#!/usr/bin/env -Sprintf [%s]\n first second third

I should have used this hashbang:

#!/usr/bin/env -S-- printf [%s]\n first second third

(So it would work even if the command were run using a name that contained an equals sign or started with a hyphen. I still don't think it would work if the command had spaces in its name. env works automatically with all of that when -S is not used, but -S complicates it.)

Wait, that's not right.

I mean all those hashbangs work.

Sorry, yeah, that's right. But I should have been clear that the "command name" I'm talking about is that of the interpreter, in this case printf. Since that's hardcoded into the hashbang, there's no actual risk of a weird rename to the file containing the hashbang to cause problems.

← 13 messages moved from Raiders of the Lost Downboat

@EliahKagan that's neat!

The reason -S is useful is that, in a hashbang, the interpreter can only be given one argument explicitly. That is, the name of the file to be interpreted is either passed as a second or third argument to the specified interpreter.

@Kulfy I'm not sure what you mean, but I did know that message was a reply to that message. I just still didn't make the connection. I tend to call -w (or more precisely, the w) an "option," but the word "flag" is just as good, I just don't use it as much myself, which might be why I didn't understand your meaning.

I see. I prefer flags (don't know why)

One syllable? Brevity is an advantage.

@Kulfy When I started saying "option" instead of "flag" the reason was to avoid confusion with the related but not quite identical idea of a "flag" in programming. (For example, in --depth=23, --depth does not likely correspond to a flag in code.) I'd had conversations in which this ambiguity had actually been a problem... or I thought it had at the time, anyway. I don't remember the details of them now.

The thing is, "flag" isn't IMO that useful a word in programming anyway (especially when it's used as a variable name!). The other thing is, "option" also has a meaning that is specific to programming (an option type for a type T is a type whose values can hold any value of T, plus one other value indicating the absence of a T, which some languages' type systems directly support). So this is not a reason to prefer "option" to "flag."

These days, I still prefer "option" to "flag" in most of my own speech and writing, but the reason is different: we have the phrase "non-option argument," but there is no commonly recognized phrase like "non-flag argument," so for consistency I say "option" in other cases too.

TBH when I started using Linux, I found "flag" in many manpages. I got habitual of "flags".

Which OSes had you used previously?

CentOS, Kali and Mint. Kali and Mint for very short duration. CentOS for about 4-5 months.

I mean before you started using Linux and read about flags in manpages.

Windows :P

← 11 messages moved from Raiders of the Lost Downboat

@Kulfy Windows has command-line options/flags too. Though oddly they're often called "switches" (as they were in DOS). For example, from the output of set /?:

Two new switches have been added to the SET command:

    SET /A expression
    SET /P variable=[promptString]

I find Windows CMD very restricting. So I tend to avoid commands in Windows unless it's important.

Well, PowerShell is more powerful than the traditional Windows shell cmd.exe.

Indeed.

I don't really know PowerShell though. I've been meaning to learn it one of these days.

PowerShell Core officially supports Ubuntu even. Though I haven't managed to get it to actually run. :(

It would probably help if I installed .NET Core on the Ubuntu system where I installed the PowerShell Core snap. But as a snap shouldn't it carry its dependencies? Or at least tell me about their absence?

PowerShell is good. AFAIK PS supports Ubuntu via WSL.

@EliahKagan That makes sense

@Kulfy Do you mean I can install PowerShell for Ubuntu in a WSL system? Or something else?

@EliahKagan I mean Powershell in Windows.

I don't use snaps.

Snaps creates some loopback partitions which increases boot time. And I hate that.

Well, Ubuntu on WSL doesn't currently support snaps anyway. (Maybe WSL2 does though, I don't know. I haven't used that.)

@Kulfy Are you saying that, in Windows 10, I can navigate into WSL systems' flesystems and safely operate on them?

If so, I am quite happy to hear of this.

@EliahKagan I have planned to try WSL2 soon.

@EliahKagan Yeah. I believe that's what WSL2 introduced.

I am having difficulties in getting how WSL actually works internally.

Like what actions it perform to actually convert Linux system calls into Windows system calls.

if it is not if-else.

@Kulfy Oh. I was hoping I could do that in WSL1.

Unfortunately no.

That's okay. VS Code's "remote" integration with WSL is sufficient. :)

Oh. What do you mean by "remote"? I am not aware of that.

I mean these extensions.

I see.

The extension for WSL uses basically the same interface as the extension for remote editing on a non-WSL GNU/Linux system (which isn't specific to Windows).

It's worth trying then.

They both upload vscode-server to the system on which remote editing will be performed. This runs and functions as the backend. It can have extensions installed on it and everything. The remote machine does need to be an x86_64 GNU/Linux system (WSL or otherwise). Regular remote editing communicates with the remote machine via normal SSH so it should have that installed. (With WSL, vscode takes care of it and nothing special has to be set up first.

The remote machine can have VS Code (the client) on it or not. Either way that's not used and doesn't share extensions with the server, so they can be different versions/builds and if one breaks the other is unaffected.

(On the remote machine, the server's files are stored in ~/.vscode-server, while the client's files all remain in the usual location of ~/.vscode.)

Well that sounds good. MS is going good. At least they are not just pushing their products. Like if you want to use this feature, then you need to install VS Code on remote machine too.

It would often not make sense for the VS Code client to be installed on the remote machine, because it might have no GUI. It might even be a container with a stripped-down system installed in it. (Also, this is used for WSL, where installing the VS Code client is deliberately not supported and does not seem to work--I've tried that to see.)

I tried installing firefox and X.Org on WSL and tried hard if I could make it work. But failed.

I wouldn't expect that to work (it would probably install, but I don't think it would run and work).

But there are X servers for Windows that you can install and run, like VcXsrv.

And programs running in a WSL system can display to them.