text:
Use ArgumentList when invoking native executables

Handling Parameter Binding in Native Executables
PowerShell generally provides a useful experience when working with native executables, but there are a number of issues:

passing embedded quoted strings is very problematic
passing an empty string is very problematic (mostly impossible)
passing a string which looks like a ScriptBlock requires extra care

A command line such as: msiexec /i testdb.msi INSTALLLEVEL=3 /l* msi.log COMPANYNAME="Acme ""Widgets"" and ""Gizmos""" is received as: msiexec /i testdb.msi INSTALLLEVEL=3 /l* msi.log COMPANYNAME="Acme Widgets and Gizmos". A command line such as: msiexec /i testdb.msi INSTALLLEVEL=3 /l* msi.log COMPANYNAME="Acme ""Widgets"" and ""Gizmos.""" is received as: msiexec /i testdb.msi INSTALLLEVEL=3 /l* msi.log COMPANYNAME="Acme Widgets and Gizmos." which strips the embedded double quotes.
Current behavior does not allow empty strings to be passed, so the following is not possible:

useradd -g 501 -u 1001 -p '' sam
emacsclient -u ''

These behaviors should be supported as there are many scenarios where an empty string is required as a parameter value.
Handling Quotes
Windows and Non-Windows have divergent behavior with regard to quotes.
While both Windows and Unix shells recognize "one two three" as a single string,
Windows does not recognize single quotes ' as string designator.
Unix shells (and PowerShell) has 2 types of strings;
Expandable strings "$a" where $a is expanded with the value of the variable $a, and literal strings '$a'where the literal string$a` is passed.
In the case of Windows a string such as 'foo bar' is 2 tokens ('foo and bar') where Unix will see a single string foo bar.
Null vs Empty Strings
Most shells don't have the same definition of null that PowerShell does.
In bash, for example, commands are invoked via strings, so naturally, an empty string can be easily notated with '' or "".
Similarly, in CMD.EXE an empty string may be passed with "".
However, the following should not result in empty strings being added:

$null
Reference to a variable which is unassigned
Reference to a variable which is assigned the value $null
When a collection wherein an element of the collection has the value $null

Non-null elements of a collection will be bound:

@($null, 1, $null) will bind a single value 1 as a parameter value
@($null, 1, $null, 2, $null) will bind 2 values (1 and 2) as parameter values
@($null, 1, $null, '', 2) will bind 3 values (1, '', 2) as parameter values

examples:
PS> useradd -g 501 -u 1001 -p $null sam # error - "sam" is used as password and no username is passed
PS> $a = $null
PS> useradd -g 501 -u 1001 -p $a sam # error - "sam" is used as password and no username is passed
PS> $a = @()
PS> useradd -g 501 -u 1001 -p $a sam # error - "sam" is used as password and no username is passed
PS> $a = @($null)
PS> useradd -g 501 -u 1001 -p $a sam # error - "sam" is used as password and no username is passed
PS> $a = ''
PS> useradd -g 501 -u 1001 -p $a sam # no error - empty string is passed as password
PS> $a = @('')
PS> useradd -g 501 -u 1001 -p $a sam # no error - empty string is passed as password
PS> $a = @('',"sam")
PS> useradd -g 501 -u 1001 -p $a # no error - empty string is passed as password and same is passed as username value
PS> $a = @("-g",501,"-u",1001,"-p",'',"sam")
PS> useradd $a # no error
PS> $a = @("-g",501,"-u",1001,$null,$null,$null,$null,"-p",'',"sam")
PS> useradd $a # no error - nulls are not passed

Additional Examples
S> msiexec /i A:\Example.msi PROPERTY="Embedded ""Quotes"" White Space" # no error - embedded quotes are passed to native executable
PS> msiexec /i A:\Example.msi PROPERTY="Embedded White Space" # no error - embedded spaces are passed to native executable
PS> msiexec /i A:\Example.msi PROPERTY="" # no error - empty string is passed to native executable

Globbing Considerations
Globbing will need to be done where appropriate. This behavior is platform dependent, so on Windows systems, globbing is not performed but is provided on Linux and Mac systems. This is because most utilities on Windows do their own globbing, but on Linux and Mac globbing is done by the shell. The current behavior for globbing does this and needs to remain unchanged to ensure that the scenarios continue to work on each platform. When a glob fails, the string provided shall be sent to the application without alteration.
The following example shows the difference based on platform:
PS> # on Windows
PS> .\echoit.exe rm c:\tmp\dd\f*
Argument 1 <rm>
Argument 2 <c:\tmp\dd\f*>

# on Mac/Linux
PS> trace-command -pshost -name parameterbinding { /bin/ls /tmp/dd/f* }
DEBUG: 2021-02-08 17:12:03.3886 ParameterBinding Information: 0 : BIND NAMED native application line args [/bin/ls]
DEBUG: 2021-02-08 17:12:03.3887 ParameterBinding Information: 0 :     BIND argument [/tmp/dd/f1 /tmp/dd/f2]
DEBUG: 2021-02-08 17:12:03.3956 ParameterBinding Information: 0 : CALLING BeginProcessing
/tmp/dd/f1
/tmp/dd/f2
PS> trace-command -pshost -name parameterbinding { /bin/ls /tmp/dd/fff* }
DEBUG: 2021-02-08 17:12:23.0600 ParameterBinding Information: 0 : BIND NAMED native application line args [/bin/ls]
DEBUG: 2021-02-08 17:12:23.0601 ParameterBinding Information: 0 :     BIND argument [/tmp/dd/fff*]
DEBUG: 2021-02-08 17:12:23.0670 ParameterBinding Information: 0 : CALLING BeginProcessing
ls: /tmp/dd/fff*: No such file or directory

Unsupported or Requiring Alteration
Some elements may not be used as they represent PowerShell tokens.

An embedded semi-colon ; is not allowed. PowerShell will parse this as a statement separator.
An open curly-brace will be interpreted as the beginning of a scriptblock

for example:
msiexec /p msipatch.msp;msipatch2.msp /n {00000001-0002-0000-0000-624474736554} /qb

This is not allowed because of the embedded ; which PowerShell will turn into 2 commands (; is a statement separator) this string must be quoted.
This is also not supported because of the use of ScriptBlock syntax. PowerShell can not determine if the ScriptBlock is a command (or in this case a guid).
To execute this command, quote the problematic strings or use --% after the executable.

msiexec /p 'msipatch1.msp;msipatch2.msp' /n '{00000001-0002-0000-0000-624474736554}' /qb
or
msiexec --% /p msipatch1.msp;msipatch2.msp /n {00000001-0002-0000-0000-624474736554} /qb
NB: The behavior for supporting ScriptBlocks as strings could be supported via an allow-list for known executables. This may be needed because the amount of GUIDs (with braces) is used in a number of both Windows and Non-Windows utilities. However, managing the list of utilities may be burdensome.
Improved Tracing
The parameter binding tracing code for native executables is not currently implemented which makes debugging issues when execution native applications very difficult. Tracing for current parameter binding and new behavior shall be provided. In the case of the old style, the path to the executable and the string which makes up the Arguments property of the StartInfo object shall be provided. For the new behavior, since the arguments are a list, each element of the list shall be presented.
The following transcript shows how the tracing shall appear.
# new style - native arguments are bound to ArgumentList property
PS > trace-command -PSHOST -Name ParameterBinding { ~/echoit foo="bar ""blob"" bar" zap foo:bar:baz,bip,bar }
DEBUG: 2021-02-04 17:28:54.5674 ParameterBinding Information: 0 : BIND NAMED native application line args [/Users/james/echoit]
DEBUG: 2021-02-04 17:28:54.5674 ParameterBinding Information: 0 :     BIND cmd line arg [foo=bar "blob" bar] to position [0]
DEBUG: 2021-02-04 17:28:54.5675 ParameterBinding Information: 0 :     BIND cmd line arg [zap] to position [1]
DEBUG: 2021-02-04 17:28:54.5675 ParameterBinding Information: 0 :     BIND cmd line arg [foo:bar:baz,bip,bar] to position [2]
DEBUG: 2021-02-04 17:28:54.5728 ParameterBinding Information: 0 : CALLING BeginProcessing
Argument 1 <foo=bar "blob" bar>
Argument 2 <zap>
Argument 3 <foo:bar:baz,bip,bar>

# old style - native arguments are bound to Arguments property
PS > trace-command -PSHOST -Name ParameterBinding { ~/echoit foo="bar ""blob"" bar" zap foo:bar:baz,bip,bar }
DEBUG: 2021-02-04 17:29:01.9987 ParameterBinding Information: 0 : BIND NAMED native application line args [/Users/james/echoit]
DEBUG: 2021-02-04 17:29:01.9987 ParameterBinding Information: 0 :     BIND argument ["foo=bar "blob" bar" zap foo:bar:baz,bip,bar]
DEBUG: 2021-02-04 17:29:02.0058 ParameterBinding Information: 0 : CALLING BeginProcessing
Argument 1 <foo=bar blob bar>
Argument 2 <zap>
Argument 3 <foo:bar:baz,bip,bar>
PS >

# view of tracing when --% is used
PS /Users/james> trace-command -PSHOST -name parameterbinding { ~/echoit --% 'foo bar' a,b,c "one two" "a\ b\ c"
>> }
DEBUG: 2021-02-08 17:07:10.0199 ParameterBinding Information: 0 : BIND NAMED native application line args [/Users/james/echoit]
DEBUG: 2021-02-08 17:07:10.0199 ParameterBinding Information: 0 :     BIND cmd line arg ['foo] to position [0]
DEBUG: 2021-02-08 17:07:10.0199 ParameterBinding Information: 0 :     BIND cmd line arg [bar'] to position [1]
DEBUG: 2021-02-08 17:07:10.0199 ParameterBinding Information: 0 :     BIND cmd line arg [a,b,c] to position [2]
DEBUG: 2021-02-08 17:07:10.0200 ParameterBinding Information: 0 :     BIND cmd line arg ["one] to position [3]
DEBUG: 2021-02-08 17:07:10.0200 ParameterBinding Information: 0 :     BIND cmd line arg [two"] to position [4]
DEBUG: 2021-02-08 17:07:10.0200 ParameterBinding Information: 0 :     BIND cmd line arg ["a\] to position [5]
DEBUG: 2021-02-08 17:07:10.0200 ParameterBinding Information: 0 :     BIND cmd line arg [b\] to position [6]
DEBUG: 2021-02-08 17:07:10.0200 ParameterBinding Information: 0 :     BIND cmd line arg [c"] to position [7]
DEBUG: 2021-02-08 17:07:10.0261 ParameterBinding Information: 0 : CALLING BeginProcessing
Argument 1 <'foo>
Argument 2 <bar'>
Argument 3 <a,b,c>
Argument 4 <"one>
Argument 5 <two">
Argument 6 <"a\>
Argument 7 <b\>
Argument 8 <c">

Additional considerations for tracing
It may be desirable to add additional tracing which provides information on the parameters as they were provided.
The tracing above is created at the point where the StartInfo object is populated,
and it may be useful to see the parameter before it is altered by globbing, etc.
Current Implementation
When PowerShell starts a new native process it takes all the arguments provided and attempts to stitch together the various parts into a single string (which is assigned to the Arguments property of the StartInfo object). This is done with some problematic behavior; empty strings '' are explicitly stripped, embedded quotes and spaces are "lost" and require addition escaping.
New Behavior
I think we can do better and reduce the effort and internal complexity when calling native applications. Dotnet has added a new property to the StartInfo object called ArgumentList which allows you to provide the arguments to the command as a collection of strings, alleviating the need to stitch the arguments into a single string. We can take advantage of this new API to reduce the complexity of our code. However, we should maintain backward compatibility if we can, so rather than producing new, breaking behavior via an experimental feature, I suggest that we provide a new runtime behavior based on a PowerShell variable. This allows users to change the behavior without restarting the PowerShell process and can be used when desired.
By not changing the default behavior we can provide users an easy way opt-in to the new behavior. Telemetry can be added if desired to capture the count of how many times the current way is used in comparison with this new implementation.
NB: This proposal will actually increase the internal complexity of our code because we'll have 2 ways of calling native applications. Hopefully, this would be temporary and we can use the new APIs exclusively in the future and deprecate the current code.
Tools used
The following utility is used to echo all passed parameters given in the examples above. This does not rely on the CLR runtime, but may be compiled for all platforms.
#include <stdio.h>
int main(int argc, char *argv[])
{
    for(int i = 1; i < argc; i++) {
        printf("Argument %d <%s>\n", i, argv[i]);
    }
    return 0;
}

We can add this to the tools for build if needed (either by binaries checked in for each platform or build)
Related Links:
Pull Requests

https://github.com/PowerShell/PowerShell/pull/14692 (the PR to implement the behaviors listed here)
https://github.com/PowerShell/PowerShell/pull/13483

Issues

https://github.com/PowerShell/PowerShell/issues/13068
https://github.com/PowerShell/PowerShell/issues/13428
https://github.com/PowerShell/PowerShell/issues/1995

By not changing the default behavior we can provide users an easy way opt-in to the new behavior

I suggest to rather have the new behavior by default and use the PowerShell variable rather for opting out of the new behavior. Especially with previews, it will allow people to discover whether they need to adapt their code or to give feedback that would allow tweaking of this new feature.

Should this not go as an experimental feature as opposed to using an environmental variable to control it?

By not changing the default behavior we can provide users an easy way opt-in to the new behavior

I suggest to rather have the new behavior by default and use the PowerShell variable rather for opting out of the new behavior. Especially with previews, it will allow people to discover whether they need to adapt their code or to give feedback that would allow tweaking of this new feature.

How often would that break existing code?

I think the right approach with respect to enabling the new behavior is:

Have the new preference variable default to the OLD behavior, and require opt-in to the new behavior; as suggested in https://github.com/PowerShell/PowerShell/pull/14692#issuecomment-773391188, it could be a $PSNativeCommandArgumentPassing (perhaps $PSNativeArgumentPassing is enough) with possible values Legacy (default, old behavior) and Standard (new behavior).

Needing an opt-in is highly unfortunate, given that argument-passing to external programs is a core mandate of any shell, but if backward-compatibility is paramount, it's our only choice.

Introduce a temporary experimental feature that makes the engine act as if the opt-in were in place - i.e. it acts as if $PSNativeCommandArgumentPassing were set to Standard (even if it is set to Legacy or the variable is missing); thereby, the new behavior will be in effect by default for preview users.

However, visibility of experimental features and their current state is a problem in general - see #14862 for a suggested improvement.

In the case at hand, is of vital importance that the new feature be widely publicized, to encourage people to put it to the test.

As for the proposal:

Being able to trace native parameter passing will be a welcome addition on Windows (and in legacy mode on Unix).

The following behaviors mentioned in the OP are incidental to the proposal:

No changes from the current behavior:

$null values are already ignored, both as individual arguments and as collection element.
native globbing already works (though, as an aside, it is worth mentioning that this globbing is always case-insensitive, unlike the native behavior on Linux, and you get no control over whether hidden items are also matched)

N/A, due to how processes are launched on Unix-like platforms (the quoting styles of POSIX-compatible shells such as bash are irrelevant here):

Quoting only applies to shells on Unix, whose job is to parse a command line - a single string encoding a command name and  its arguments - into the command name and the array of verbatim arguments to pass to it.
Unlike on Windows, (non-shell) processes do not receive a command line - they only ever receive an array of verbatim arguments - that's precisely what .ArgumentList gives us, and it fully solves all problems on Unix.

Unfortunately, things aren't quite so simple on Windows, due to launched processes receiving a command line that they themselves must parse. This very unfortunate design forces processes to take on part of a job that should be exclusively a shell's responsibility: parsing this command line into an array of verbatim arguments.
Aside from placing undue burden on non-shell processes, it opens the door to individual processes interpreting their command line however they want:
While there is a widely adhered-to convention for how to encode multiple arguments in such a process command line - namely the ones used by Microsoft's C / C++ compiler / the CLR (which I'll call the C convention here) - no single encoding is guaranteed to work with all programs:

The most prominent exception is cmd.exe - and therefore calls to batch files: they accept only "" as an escaped ", not the \" required by the C convention); while Microsoft compiler-generated executables also support "", there are third-party programs that support only \")

An additional problem is that batch files unfortunately and inappropriately parse their arguments as if they had been passed from inside cmd.exe, which causes something like .\foo.cmd http://example.org?foo&bar to break due to & being misinterpreted as a statement separator. Using "http://example.org?foo&bar", i.e. quoting from PowerShell doesn't help, because PowerShell - justifiably - omits the quotes when it rebuilds the process command line behind the scenes,  given that value contains neither spaces nor embedded " chars.

This is especially problematic given that the CLIs of many high-profile environments (e.g., Azure, Node.js) use batch files as their CLI entry points, so that something like az ... http://example.org?foo&bar predictably fails.

Finally, many programs are particular about partial quoting of arguments, notably msiexec.exe with property arguments such as PROP="VALUE WITH SPACES"; purely syntactically, "PROP=VALUE WITH SPACES" (which is what PowerShell currently sends) should be equivalent (and if you let C runtime / CLR parse it, is - the resulting verbatim string is PROP=VALUE WITH SPACES in both cases), but in practice it is not.

PowerShell should not pay attention to the original quoting on the PowerShell command line in an attempt to emulate it when re-encoding behind the scenes; no such quoting may be present to begin with (e.g., PROP=$someValuePossiblyWithSpaces), and users generally shouldn't have to worry about such intricacies - see below.

It's impossible for PowerShell to fully solve these problems, but it makes sense to make accommodations for these exceptions, so as to make the vast majority of calls just work - for the remaining, edge cases there is --%
In concrete terms this means for the new behavior:
After PowerShell's own parsing, once the array of verbatim arguments to pass on is available:

On Unix-like platform:

Pass that array to .ArgumentList - that is all that is ever needed.

On Windows:

Except for the cases detailed below, also pass that array to .ArgumentList - behind the scenes, .NET performs the necessary re-encoding based on the C conventions for us, and any conventional CLI should interpret the result correctly.

The following exceptions may apply independently or in combination, and they require manual re-encoding by PowerShell (with assignment to .Arguments, as currently):

If the target command is a batch file:

use "" (rather than \") to escape embedded verbatim " (and ensure enclosure in syntactic "...", even if the value has no spaces)
"..."-enclose any argument that contain no spaces (such arguments are normally not quoted) but contain any of the following cmd.exe metacharacters: & | < > % ^ (for intra-batch file parsing, additional metacharacters apply, but these are the ones that must be passed inside "..." for argument pass-through with %* not to break or malfunction).

Irrespective of the target executable, if any of the arguments has the form of a misexec-style partial-quoting argument, apply double-quoting only the "value" part (after the separator):

Specifically, if an argument (a) matches regex ^([/-]\w+[=:]|\w+=)(.+)$, and (b) the part after = or : requires double-quoting (either due to containing spaces and/or an embedded " and/or, in the case of a batch file containing cmd.exe metacharacters), leave the part up to and including = or : unquoted, and double-quote only the remaining part.
Examples:

The following PowerShell arguments:

FOO='bar none', -foo:$value (with $value containing verbatim bar none), /foo:bar` none (and even quoted-in-full variants 'FOO=bar none', ....)

would end up in the .Arguments command line as follows:

FOO="bar none", -foo:"bar none", /foo:"bar none"

Again, these are reasonable accommodations to make, which:

allow users to focus solely on PowerShell's syntax
should make the vast majority of calls just work.
are easy to conceptualize and document - the proposed tracing should help too.

I invite everyone to scrutinize these accommodations to see if they're complete, overzealous, ...
This is a chance to finally cure all native quoting / argument-passing headaches - even if only by opt-in.

Have the new preference variable

It should be noted that additional runtime behavior altering preference variables is not without risk. With each one added, the amount of ceremony required to guard against inherited preferences is increased heavily.
I'm not weighing in on whether it's the right call in this scenario, just want to make sure that's considered.

Yes, that is a concern with all preference variables, and the lack of lexical scoping is surely a candidate for #6745.
The - not exactly obvious - workaround is to use the $private scope:
# Predefined preference variable:
#  - defaults to 'Legacy'
#  - is NOT defined with option 'AllScope'
$global:PSNativeArgumentPassing = 'Legacy'

& {

    # Override the global preference variable *for this scope only*.
    $private:PSNativeArgumentPassing = 'Standard'

    "In child scope: $PSNativeArgumentPassing"

    # Thanks to $private, descendant scopes again see the global variable.
    & {
      "In grandchild scope: $PSNativeArgumentPassing"
    }

}

I hope there's no question that:

introducing the new behavior is a must.
in-session control must be available as to which scopes adopt the new behavior vs. which ones do not.

In light of that, @SeeminglyScience: can you think of a different current-scope-only opt-in mechanism?

Yes, that is a concern with all preference variables

It's a little less of an issue since most of the existing preference variables are only going to change behavior that is already leaking to the user. Like error preference, usually when that changes runtime behavior it's when you're emitting an error to the user.
I do say "usually" there because it can for sure end up forcing a different code path, but doesn't change the meaning of your code.  Also either way, the more that are added the harder it is to guard against.

In light of that, @SeeminglyScience: can you think of a different current-scope-only opt-in mechanism?

Current scope isn't necessarily what you want either, too many things create a new scope where most users would not necessarily expect it.
Parser based lexical scoping does solve that problem, but creates a new one in the form of a new dialect which is very expensive in the long term.
I don't know of a way to make a change like this without one of these extra chunks of complexity or breaking changes.

Thanks, @SeeminglyScience - sounds like a preference variable is our only - imperfect - realistic short-term option.
(A quick aside: $PSDefaultParameterValues is the one preference variable that potentially has the farthest-reaching consequences, especially since modifying it directly in any scope modifies the global copy; fortunately, it doesn't seem to be used all that much in practice).
In practice, in terms of guiding users, this means:

Set the global copy of $PSNativeArgumentPassing to 'Standard' if you want all code in your session to exhibit the new behavior.

Set a (non-global) scope-specific copy for that scope and all its descendant scopes to exhibit the new behavior - but not across module boundaries.

Set $private:PSNativeArgumentPassing to exhibit the new behavior in that scope only - which requires knowledge of what does and doesn't run in a child scope (the rules for which are indeed not always clear - see #7157).

A good experiment might be to try a whole lot of different build scripts for that use various toolsets and see how often they break with the new setting. That will be a prime example of accidental inheritance with often complex executable arguments.
Personally I'd still lean toward the stop parsing sigil being the way to go, but in all honesty this issue has rarely affected me in a meaningful way so ymmv.

I'd still lean toward the stop parsing sigil

Unfortunately, --%, the stop-parsing symbol:

on Windows: is cumbersome and has non-obvious behavior and limitations - and you need to know when it is actually needed, which is a big part of the problem - see https://github.com/MicrosoftDocs/PowerShell-Docs/issues/6149

on Unix: is a misnomer by definition (parsing must happen there, in the absence of process-level command lines) and is virtually useless there, if you expect the behavior of the native shell - see https://github.com/MicrosoftDocs/PowerShell-Docs/issues/4963

this issue has rarely affected me in a meaningful way

I presume that's because you're a developer rather than a sysadmin or DevOps person.
As the following can attest:

#1995 (up-votes and the length of the discussion)
#13068  (in the sense that delegating to the native shell would be an attempt to bypass the problem)
untold questions by users struggling with broken quoting on https://stackoverflow.com and sister sites such as https://superuser.com
https://github.com/MicrosoftDocs/PowerShell-Docs/issues/2361

the issue at hand is a real, long-standing pain point.
And the issue is an even bigger one on Unix, where - unlike on Windows - many capable native utilities exist, and that for performance reasons and lack of binary pipeline support resorting to native utilities is sometimes a must.
It all comes back to this striking example (run on a Unix-like platform):
PS> /bin/echo '{ "foo" : 1 }'
{ foo : 1 }  # !! double quotes were effectively stripped

This is such blatantly broken behavior that you can't help but wonder why this hasn't been fixed - even if only on an opt-in basis - in the 14+ years of PowerShell's existence.

Unfortunately, --%, the stop-parsing symbol:

I mean the new one being proposed in a different issue somewhere.

I presume that's because you're a developer rather than a sysadmin or DevOps person.

I'm a sysadmin.

As the following can attest:

I included that last part as a disclaimer on my opinion, not as a dismissal of the need. Put more casually and a bit exaggerated it would be "I think it should be X but what I do I know, I don't run into this problem".

I mean the new one being proposed in a different issue somewhere.

I assume you mean the aforementioned #13068  ("native operator") - its purpose is different, requires you to apply a different shell's syntax and, without using a (here-)string as enclosure, is subject to the same conceptual headaches as --%. In short: it is not meant to address the problem at hand, and it would so poorly - see https://github.com/PowerShell/PowerShell/issues/13068#issuecomment-653319079
That said, a new call operator - to be used explicitly, in lieu of &  (which also come up in the same thread, at https://github.com/PowerShell/PowerShell/issues/13068#issuecomment-653526374) - might be a low-ceremony alternative that avoids the preference-variable scoping headaches.
Finding the right sigil combination (I don't think a single character is an option), may be a challenge (&! was mentioned), and, of course, it would be a very visible reminder in every call that extra effort is needed to get argument-passing to act correctly.

I'm a sysadmin.

Kudos on the extraordinary depth of your programming knowledge (just to be very clear: I mean it).

"I think it should be X but what I do I know, I don't run into this problem".

Understood. I just wanted to complement that with a transpersonal perspective, to leave no doubt that many others do struggle with this.

I made a mistake (since corrected, and is correct in the ie function) in the list of metacharacters that in batch-file calls should trigger double-quoting even for space-less arguments: the correct list is  & | < > ^ , ;
The reason that , and ; are on that list is that cmd.exe interprets them as argument separators in an unquoted token; for instance,  in .\foo.cmd 'a,b' and .\foo.cmd 'a;b' the respective argument is currently (justifiably) passed as unquoted a,b and a;b to batch files, and if they do individual parameter processing with %1, ... or shift (as opposed to all-arguments pass-through with %*), they see two arguments: a binds to %1, and b to %2 - that is, the calls are effectively the same as using the usual whitespace-based argument separation: .\foo.cmd a b.

Making PowerShell pass "1,2" and "1;2" in this case preserves the ability to pass such arguments as-is, without needing to resort to --% - and if truly   two arguments are to be passed, whitespace separation can be used.

Note that that above additionally applies to =, but it is not on the list, because it conflicts with the other accommodation, namely the one for msiexec-style programs: <name>=<value> should always leave the <name>= part unquoted.

Given the diminishing importance of batch files (other than mere CLI entry points that pass all arguments through), it makes sense to me to prioritize this accommodation.

Again, what we should strive for is accommodations that:

make the vast majority of calls "just work"
based on rules that are as easy to conceptualize and remember as possible, and are clearly documented along with workarounds.

There is another accommodation we need to make:

Direct cmd.exe calls that pass a command (line) to execute in the form of either cmd.exe [<options>] /c <command> or cmd.exe [<options>] /k <command>

For a single-argument <command> - which is ultimately the only robust way to pass a command line - this currently works as-is due to a happy accident:

PowerShell's current lack of escaping of embedded " is canceled out by cmd.exe not expecting any escaping and blindly stripping enclosing "...".

If we don't keep handling this case the way we do now (see below), we would break something that currently works as-is (no workaround needed).

As an aside: Passing a command line as a single string to the platform-native shell - without having to worry about quirks and specific option names - is what the Native module's ins / Invoke-NativeShell cmdlet is designed to do, and I think such a cmdlet is called for as part of PowerShell, as the proper solution to #13068 (rationale in https://github.com/PowerShell/PowerShell/issues/13068#issuecomment-653319079).

Example:
# A command line to pass to cmd.exe for execution.
# If executed correctly, the following should print verbatim:
#       Ready to move on [Y,N]?Y
$cmdLine = ' "C:\WINDOWS\system32\choice.exe" /d Y /t 0 /m "Ready to move on" '

# !! Despite the lack of behind-the-scenes escaping of the embedded double quotes,
# !! this currently works *as intended*, in both editions:
cmd /c $cmdLine

What PowerShell currently translates the list of arguments to behind the scenes and assigns to .Arguments is the following verbatim string (I've prepended cmd so that it's easy to execute the command interactively from a cmd.exe session):
cmd /c " "C:\WINDOWS\system32\choice.exe" /d Y /t 0 /m "Ready to move on" "

That is, the verbatim content of the string that PowerShell saw was blindly enclosed in overall "..." (because the content contains spaces), without escaping embedded " chars.
As it turns out, that's exactly what cmd.exe expects - and that's the behavior we need to retain in this case.

As a courtesy, we could additionally do the following:
cmd.exe situationally allows you to pass a /c / /k command line as multiple arguments, analogous to the PowerShell CLI's -Command / -c parameter.
However, that breaks - through cmd.exe's own fault - if both the first argument (the executable) )and a subsequent argument are double-quoted; e.g.:
# Breaks from both cmd.exe and PowerShell, because both the first and a subsequent argument are double-quoted.
C: [PS]> cmd /c "C:\Program Files\PowerShell\7\pwsh" -noprofile -c " 'hi there' "
'C:\Program' is not recognized as an internal or external command,
operable program or batch file.

This could be avoided if PowerShell - in the event that multiple arguments follow /c or /k - transformed these multiple arguments into a single one enclosed in overall "..." quoting, with the constituent arguments internally double-quoted as needed (but, again, not escaped).
That is, PowerShell could automatically transform the above into the following verbatim string assigned to .Arguments (cmd again prepended to facilitate verification from an interactive cmd.exe session; spaces around the overall enclosing " added for readability):
# OK - transformed to single-argument command line, which works robustly - outputs 'hi there'
cmd /c " "C:\Program Files\PowerShell\7\pwsh" -noprofile -c " 'hi there' " "

In fact, this is what the ie function from the Native module does as of v1.2.1:
# Without `ie`, this breaks.
PS> ie cmd /c 'C:\Program Files\PowerShell\7\pwsh' -noprofile -c " 'hi there' "
hi there

Direct cmd.exe calls that pass a command (line) to execute in the form of either cmd.exe [<options>] /c <command> or cmd.exe [<options>] /k <command>

Ahh that explains why I don't run into this issue much.  The few times that I need to invoke an executable with enough argument complication, I tend to build the whole command line as a single string and pass it to cmd.exe /c.

Addressed as part of PSNativeCommandArgumentPassing feature

authors: JamesWTruher SeeminglyScience SteveL-MSFT bergmeister kilasuit mklement0 sba923


text:
Invalid powershell.config.json makes PowerShell unusable

When a powershell.config.json file is set, there's no handling of an invalid file. Essentially it breaks the whole PowerShell session, and since PowerShell is broken, you can't use Remove-Item to unbreak it...
Steps to reproduce
Write some invalid JSON to the powershell.config.json.
On Windows this is at ~\Documents\PowerShell\powershell.config.json.
On *nix this is at ~/.config/powershell/powershell.config.json.
Write something like:
banana

Actual behavior
Trying to start a new PowerShell session looks like this:

Unhandled Exception: Newtonsoft.Json.JsonReaderException: Unexpected character encountered while parsing value: b. Path '', line 0, position 0.
   at Newtonsoft.Json.JsonTextReader.ParseValue()
   at Newtonsoft.Json.JsonTextReader.Read()
   at Newtonsoft.Json.JsonReader.ReadForType(JsonContract contract, Boolean hasConverter)
   at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.Deserialize(JsonReader reader, Type objectType, Boolean checkAdditionalContent)
   at Newtonsoft.Json.JsonSerializer.DeserializeInternal(JsonReader reader, Type objectType)
   at Newtonsoft.Json.JsonSerializer.Deserialize[T](JsonReader reader)
   at System.Management.Automation.Configuration.PowerShellConfig.ReadValueFromFile[T](ConfigScope scope, String key, T defaultValue, Func`4 readImpl)
   at System.Management.Automation.Configuration.PowerShellConfig.GetPowerShellPolicies(ConfigScope scope)
   at System.Collections.Concurrent.ConcurrentDictionary`2.GetOrAdd(TKey key, Func`2 valueFactory)
   at System.Management.Automation.Utils.GetPolicySettingFromConfigFile[T](ConfigScope[] preferenceOrder)
   at System.Management.Automation.Utils.GetPolicySetting[T](ConfigScope[] preferenceOrder)
   at Microsoft.PowerShell.Commands.ModuleCmdletBase.GetModuleLoggingInformation(IEnumerable`1& moduleNames)
   at System.Management.Automation.PSSnapInReader.SetSnapInLoggingInformation(PSSnapInInfo psSnapInInfo)
   at System.Management.Automation.PSSnapInReader.ReadCoreEngineSnapIn()
   at System.Management.Automation.Runspaces.InitialSessionState.ImportCorePSSnapIn()
   at System.Management.Automation.Runspaces.InitialSessionState.CreateDefault2()
   at Microsoft.PowerShell.UnmanagedPSEntry.Start(String consoleFilePath, String[] args, Int32 argc)
   at Microsoft.PowerShell.ManagedPSEntry.Main(String[] args) in C:\PowerShell\src\powershell\Program.cs:line 22

In some scenarios (I haven't worked out which yet) almost random failures seem to occur mid-PowerShell session (i.e. you have a working PowerShell session then create a bad powershell.config.json file). Such as:
> Invoke-Build Test
Invoke-Build : AuthorizationManager check failed.
At line:1 char:1
+ Invoke-Build Test
+ ~~~~~~~~~~~~
+ CategoryInfo          : SecurityError: (:) [], PSSecurityException
+ FullyQualifiedErrorId : UnauthorizedAccess

(Deleting the bad powershell.config.json makes this work again)
Expected Behaviour
For this to work as a robust feature, I would expect:

A good user-facing error message stating that the powershell.config.json file is malformed or otherwise invalid.
PowerShell should ignore the config file entirely if there is a problem with it
You should still be able to use cmdlets after parsing the config file so you can dig yourself out.

Environment data

> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      6.1.0
PSEdition                      Core
GitCommitId                    6.1.0
OS                             Microsoft Windows 10.0.18242
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

PowerShell should ignore the config file entirely if there is a problem with it

Maybe better stop until user/administrator fix the file?

Well there's always the possibility of starting PowerShell with an invalid config file. So we have to handle it and the question becomes how. I see a couple of possibilities:

Crash PowerShell with a stack trace like now
Shut PowerShell down immediately and display an error message that the config file is invalid
Attempt to partially load the config file, skirting around the invalid part
Start PowerShell as if no config file were provided

In (1) and (2), the problem is that if PowerShell is the only shell you can use, you've now locked yourself out -- there's nothing you can do, because PowerShell can't be started. It's likely you have another shell or a way to delete the file on the machine, or if you're lucky someone else administers your box. But we have to support all scenarios, and having to fall back to another shell in any case doesn't seem like what we want to tell users.
That leaves (3) and (4), and to me (3) would be like finding a parse error in a PowerShell script and executing until that point anyway -- rather than what we actually do, which is execute nothing and tell the user that there's a problem.
So I think the solution is (4). PowerShell starts as if there were no config file and displays an error message with a full explanation, including:

The config file is invalid
Why it's invalid
Where it's invalid
The fact that PowerShell started ignoring it and it needs to be fixed to be loaded

you've now locked yourself out -- there's nothing you can do, because PowerShell can't be started

If exe or some dll was corrupted we'll be locked too.
I am most worried about security if we allow run with out config. If an user accidentally spoils this file and PowerShell starts, then there might be a security hole. /cc @PaulHigin @TravisEz13
Another side. What behavior is for ps1-profiles? Should we follow the rule too?

Ah that is good thinking!
On the other hand, if they have write access to the file, they could also edit it to be a different valid configuration already.

If exe or some dll was corrupted we'll be locked too.

In the pwsh.exe case there’s not a whole lot we can do.
In the DLL case I would hope for a BadImageFormatException.
Ideally in both cases signing saves us.

Profiles are just ps1 scripts right? I assume they get dot sourced at startup. If they contain a parse-error I’m guessing we never execute them, print the error and otherwise behave like no profile exists.

If we consider a scenario like login shell I guess that profiles can be critical for security too.
Maybe @mklement0 can clarify what bash behavior is in the scenario.

cc @PaulHigin

@iSazonov:
bash - and presumably other POSIX-like shells - behave the same way as described by @rjmholt with respect to PowerShell profiles (note that we don't have a startup problem per se in this case, because the shell by definition has already launched successfully by the time it attempt to source initialization files).
As for the security concern:
Perhaps switching to NoLanguage language mode if the config file cannot be read is a solution?
That would severely limit what can be done in the session (though it probably doesn't close all security holes), while still allowing calling cmdlets such as Remove-Item or invoking external programs such as an editor to fix the problem.

NoLanguage won't work for an interactive session.

We would need to turn on every security feature, some of which require configuration parameters, such as how to encrypt the script block logging.
I think the best option is to fail as @iSazonov  suggests, although the error message should be better.
The main scenario that I'm concerned about is that the admin edits the systemwide configuration and accidentally corrupts it and  then a non-admin runs PowerShell.  If we then ignore the configuration, we could ignore security setting that were intended to be deployed.

We should also think about non-interactive sessions. In the case an startup error would be invisible and useless - I'd expect that a record would be added in event log.  An error message should be better for interactive session like "write error message - sleep 5 sec - abort".

@TravisEz13
Relying on global configuration for security seems like a mistake, though -- I would have expected configuration to enable insecure things. I believe I should not have to create a global configuration to make powershell safe for everyone to use, the default state should be safe.
Can you give examples of things needed in a global config to secure powershell?

Sorry for coming late to this discussion.  I think it is Ok to just emit warning if config.json file fails to load.  I agree that the config file should not be used to configure security, and in fact we should ensure that the config file cannot affect session security.  For example PowerShell provides security guarantees in two ways:
a. When working with system wide application control such as WDAC (formerly DeviceGuard), e.g., ConstrainedfLanguage mode.
b. Remote end point sessions, e.g., LanguageMode, command, provider accessibility.
We need to make sure the config file cannot affect security stance in these cases, such as changing LanguageMode, or changing visibility of functions, cmdlets, providers, etc.

On Linux and macOS, you can only configure ScriptBlock logging and I suspect other security features via the configuration file.

source: gharchive/issue

repo: PowerShell/PowerShell

license: MIT

license_type: permissive

license_source: github-api


text:
Make sure nuget package version suffix applies to all ProjectReference

Due to a breaking change (likely by design) in dotnet-cli, dotnet pack --version-suffix doesn't apply the same suffix to all its referenced project anymore. A workaround is used.
See https://github.com/NuGet/Home/issues/4337 and https://github.com/NuGet/Home/issues/3953 for more information.

@daxian-dbw LGTM

source: gharchive/pull-request

authors: adityapatwardhan daxian-dbw


text:
updated install link and instructions for R-Pi

Removed old demo which is no longer needed

Restarted AppVeyor build.

Closing & reopening to bump status checks on CLA (this is a test, thanks for your patience)

FYI @SteveL-MSFT the CLA part is validated now

authors: SteveL-MSFT adityapatwardhan jeffwilcox msftgits


text:
Switch from BMP to PNG for graphical MSI installer assets

PR Summary
Converted the MSI's bitmaps (BMPs) to PNGs that have transparent backgrounds instead of white backgrounds.
This breaks rendering of images for Windows 7 and Server 2008R2, but it's required for accessibility purposes so that the High Contrast Black theme renders text correctly for accessibility. (Unfortunately, BMP does not support transparency.)
PR Context
In order to be fully accessible, we need to support the High Contrast Black theme in Windows. This makes system-wide text white which is unreadable on the BMP's hardcoded white background.
PR Checklist

[x] PR has a meaningful title

Use the present tense and imperative mood when describing your changes

[x] Summarized changes
[x] Change is not breaking
[x] Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
[x] This PR is ready to merge and is not Work in Progress.

If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.

User-facing changes

[x] Not Applicable
OR
[ ] Documentation needed

[ ] Issue filed:

Testing - New and feature

[x] N/A or can only be tested interactively
OR
[ ] Make sure you've added a new test if existing tests do not effectively test the code changed

/cc @bergmeister

@PoshChan Please remind me in 6 hours

@TravisEz13, this is the reminder you requested 6 hours ago

@joeyaiello Does this need to be back-ported?

It would certainly make my life easier in closing the loop with a11y folks if we could slip it into a servicing release, but if it's a huge hassle, don't worry about it.

authors: PoshChan TravisEz13 iSazonov joeyaiello


text:
Get-SecretVault -Name should be of type string[] instead of string

Get-SecretVault -Name should be of type string[] instead of string to allow returning vaults for an array of specified names.

Implemented for preview5.

authors: PaulHigin daxian-dbw

repo: PowerShell/SecretManagement


text:
Fixes for the breaking change in Pester v4

Rushing this one through so that we can resolve issues with broken tests in other PRs

This change is

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: BrianFarnhill sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

authors: BrianFarnhill msftclas

repo: PowerShell/xHyper-V

license: mit

license_source: bigquery


text:
Проблема с шагом сортировки по колонке

Укажите:

1.2.037.9
1С:Предприятие 8.3 (8.3.19.1351)
Windows 10
В клиенте тестирования установлено расширение VAExtension

При выполнении шага
И в таблице "ИмяТаблицы" текущего окна я устанавливаю сортировку по колонке "ИмяКолонки" по убыванию (расширение) возникает ошибка

База и тест для воспроизведения
[DataBase.zip](https://github.com/Pr-Mex/vanessa-automation/files/7427537/DataBase.zip)

[служебные сообщения.txt](https://github.com/Pr-Mex/vanessa-automation/files/7427542/default.txt)

Решено в https://github.com/Pr-Mex/vanessa-automation/releases/tag/1.2.039.1

authors: Pr-Mex Severnity

repo: Pr-Mex/vanessa-automation


text:
Маленькие кусочки связанные с настройками

и
просто отсортировал реквизиты

Спасибо!

authors: Pr-Mex fenixnow


text:
Merging docker labels and INI settings doesn't work as expected

My chadburn ini is as follows:
[global]
smtp-host=postfix-relay
smtp-port=25
email-to=to@mail.com
email-from=from@mail.com
mail-only-on-error=true

These values are pretty good, but sometime, i'd like to overwrite some like the email-to and/or email-from. But it doesn't really work.
As soon as I overwrite email-to AND email-from, the other global values as e.g. smtp-host or smtp-port are also overwritten:
chadburn.enabled: "true"
chadburn.job-exec.cron.email-to: "Its me <different-to@mail.com>"
chadburn.job-exec.cron.email-from: "Cron <different-from@mail.com>"
chadburn.job-exec.cron.schedule: "@every 1m"
chadburn.job-exec.cron.command: "php cron.php"
chadburn.job-exec.cron.user: "www-data"
chadburn.job-exec.cron.no-overlap: true

So with those labels, email delivery fails, because chadburn is unable to connect to the email server.
When just using these labels:
chadburn.enabled: "true"
chadburn.job-exec.cron.schedule: "@every 1m"
chadburn.job-exec.cron.command: "php cron.php"
chadburn.job-exec.cron.user: "www-data"
chadburn.job-exec.cron.no-overlap: true

everything works fine without connection failures.
My expectation is, that by merging those values, only the ones mentioned in the label will overwrite the ones in the ini file.

Oh, small side note: it would be great to also document the option user. Would be really helpful.

Same is true, if you only add/overwrite
chadburn.job-exec.check.mail-only-on-error: false

This will lead to a connection error as well. I assume, because all other server related ini values are dropped.

repo: PremoWeb/chadburn


text:
Use meta description instead of description

Rebuild #68 because it was merge on master instead of dev.
Already QA approved.

Thanks again!

repo: PrestaShop/gsitemap


text:
Remove useless include

Remove useless include. The APIFAQ class is included/called by module psgdpr module class.

Thank you @SebBareyre

repo: PrestaShop/psgdpr


text:
Do not use hook AdminStatsModules alias, use displayAdminStatsModules & Bump version to 2.0.2

Questions
Answers

Description?
Do not use hook AdminStatsModules alias, use displayAdminStatsModules

Type?
improvement

BC breaks?
no

Deprecations?
no

How to test?
n/d

Possible impacts?
n/d

Thank you @PrestaEdit

authors: PierreRambaud PrestaEdit

repo: PrestaShop/statssearch


text:
books: list view fields

As a record editor, when I’m browsing the list of books I want to see the author, short title, publication year, owning institution call number, and whether a book is extant, annotated, and/or digitized so that I can get a quick overview of volumes.

@bwhicks This is all looking great, but I think we can actually eliminate the Call Number field.

repo: Princeton-CDH/derrida-django


text:
Migrate to PUL infrastructure, postgres, and solr 8

[x] #474
[x] #475
[x] #476
[x] test migrating database and media to qa
[x] #486
[x] #477
[x] #478

Ryan finally got access and ran pgloader on the new test server — data is showing up in admin, but looks like we didn't get the timezone configured correctly:

Testing notes:
User testing:

[ ] Basic site navigation (links, interactive styles, images)
[ ] Basic keyword search (Boolean)
[ ] Advanced search (author, title, Solr search, filters)
[ ] Sort and pagination
[ ] Search within volume
Backend testing:
[ ] Search and filter
[ ] Export metadata
[ ] Edit record (change metadata, convert to excerpt, add to collection)
[ ] Add new record (HT, Gale, log)
[ ] Suppress record
[ ] Add/delete user
[ ] Add/delete collection
CMS testing:
[ ] Edit existing content
[ ] Add new editorial post

Still testing but I found that trying to convert an existing item to an excerpt in the backend generated a 500 error. The item I tried to convert is mdp.39015041158448.

There are also issues with adding new items.

For the HT items I attempted, it "Failed to sync data": hvd.32044087453239; wu.89043739457. This was also happening in production though with a different item, so I don't know whether it's a migration issue or a bug.
Trying to add a Gale item (CW0108840159) generated a 500 error.

Trying to suppress an item also generated a 500 error.
Good news is that the frontend search and navigation all looks and feels wonderful, same as production as far as I can tell.

@rlskoeser looks like the second permissions fix worked! I retested the above situations and they're all working as expected now. Thank you for the testing support! Is there any functionality you can think of that is missing in my testing list?

@mnaydan thank you for all the testing! I'm having trouble thinking of anything not on your list! I see you have cases to test adding content from both Hathi and Gale, and converting to excerpts, which were two of the things that came to mind.
You've tested keyword searching, page thumbnails, and keywords in context on individual documents? Did you test the links out to Hathi and Gale too?
When you tested editing content, did you try uploading and embedding any images?

@rlskoeser Yes, keyword search, page thumbnails (including links), and keywords in context appear normal on both main search and item detail search. The only weird thing I noticed when double checking this time is that our page number is sometimes placing a 1000 before the arabic conversion of the roman numeral page numbers for Gale content; this appears different from production (see the first hit on this page https://cdh-test-prosody.princeton.edu/archive/?query=rhyme&author=bysshe&collections=9&collections=10&collections=11&collections=3&collections=12&collections=4&collections=0&sort=relevance)
For editing content, I did upload and embed images and tested using a caption, and floating left and right (all good). I tested uploading a video too and it was very small (https://cdh-test-prosody.princeton.edu/editorial/2022/11/how-we-test-our-site/) but I don't know if that's different from how it behaves in production.

Migration to PUL complete!
@mnaydan if you want to follow up on any of those oddities you noticed, we can create new issues to track them. I don't remember ever implementing styles for video (I don't think we had any before?), so it may well not display ideally.

authors: mnaydan rlskoeser

repo: Princeton-CDH/ppa-django


text:
Wrong highlighting in C# mode : 3 slashes within a string rendered as comment

Using the following code snippet and highlight mode C# (language-csharp):
string HTML_FILEPATH = "C:/Users/sdkca/Desktop/example.html";

// and set it up using fluent notation too
configuration
.SetAllowLocalContent(true)
.SetPageUri(@"file:///" + HTML_FILEPATH);

Will produce the following result:

The 2 slashes are interpreted as a comment although it's within a string in the SetPageUri method. Neither using .SetPageUri("file://////" + HTML_FILEPATH); (without @ and escaped slashes) seems to help.
It happens in the Test drive website too.

Hi! Thanks for reporting. It should be fixed now.

authors: Golmote sdkcarlos

repo: PrismJS/prism


text:
Method 'loadLanguages' cannot import packages correctly

url: prismjs/components/index.vue
example:
code:
import loadLanguages from 'prismjs/components/index'
loadLanguages(['css'])

error:
components sync?e27f:2 Uncaught Error: Cannot find module './prism-markup'

target:
origin code:
const pathToLanguage = './prism-' + lang
line 42: delete require.cache[require.resolve(pathToLanguage)]  // Packages cannot be imported correctly here
line 45: require(pathToLanguage) // Packages cannot be imported correctly here

advice:
line 42 -> delete require.cache[require.resolve(`./prism-${lang}`)]
line 45 -> require(`./prism-${lang}`)

That's not a lot of information to work with @ModernFarmer.
May I assume that you are using Vue.js? If so, is your component rendered on the server or on the client side?

I'm using prismjs in vue3 on the client side.

In that case, the easiest solution might be to use Autoloader and a CDN. loadLanguages is intended for server-side NodeJS usage.

Ok, thank you!

Same issue for us in Electron with Webpack.
Is there any way to manually load languages without relying on script tags and plugins? Looks like maybe the Babel plugin, but I'm really just trying to create a proof of concept here, so that seems like a lot.

authors: ModernFarmer RunDevelopment Slapbox


text:
Copy to clipboard: Get around name conflict in Chrome v61+ Fixes #1181

@mAAdhaTTah Do you think this could do the trick?

tbh, the thing that bugs me about this, given Prism's target audience, is I'm not sure how many people are going to upgrade to the new version, which is part of why I'm hesitant to push in a temp fix. Users are going to have to realize the problem, trace it back to Prism (difficult on its own), then regenerate the prism.js file from the site and put it up on their site, a not-uninvolved process that could need to repeat should the browser change its behavior.
Which is why I was holding off on a fix until I got more info. I don't know if it makes more sense to push out a temp fix now and then fix it again or give it a chance to be resolved in a more permanent way.

Hm... That's a really good point I did not tought about. I think you're right. Let's give ClipboardJS some time to fix this on their own, and if need be this PR would still be usable. I'm closing for now. Thank you for reviewing!

authors: Golmote mAAdhaTTah


text:
Hotbar only updates on collect, not on place_block

Picking up dug items works nicely: the slots fill, counters increase.
But when a block is placed the number of blocks shown in a hotbar slot do not decrease. The accurate number is only obtained when you pick up another identical item and it is added to the slot.

When collecting a dug item, the bot.inventory.slot value is updated and increased.
When placing an item it is placed, the bot.inventory.slot value is not decreased. The server seems to know about it though.

Probably a flying squid issue, with fs sending slotUpdates for collection, but not for placement.

@Karang determined that it is indeed an fs issue and produced a fix that I've tested manually. I'll submit a PR tomorrow.

repo: PrismarineJS/prismarine-web-client


text:
blocked by CORS policy

The request gets denied in the console.

Can't reproduce, and this bug should not be possible.
All endpoints of patreon-dl have an open CORS policy. Are you sure you entered the browser console code on the right site?

repo: PrivateGER/patreon-dl

license: Unlicense


text:
style-book_a_cab_section

Related Issue
[Cite any related issue(s) this pull request addresses. If none, simply state “None”]
Fixes:  #155
Description
Styled the Cab/Auto Booking Form using external CSS to enhance the layout, aesthetics, and responsiveness. Replaced inline styles with a structured and organized CSS file, improving maintainability and scalability.
Issue Fixed:
The previous design of the form was too basic with inline styles, which made it difficult to manage and less visually appealing. The update addresses the need for a more modern and responsive design that adapts to different screen sizes.
Type of PR

[ ] Bug fix
[✅] Feature enhancement
[ ] Documentation update
[ ] Other (specify): _______________

Screenshots / videos (if applicable)
before css

after css

Let me know if you want any specific details added or further changes!
thank you 🙂

@Karnmayank07 Please see the conflicts . Resolve the conflicts . Ensure you pull all the latest changes before pushing your feature/bug fixes to the main branch. After resolving the conflicts, please open a new PR for review.
Thank you!

@Karnmayank07 Please see the conflicts . Resolve the conflicts . Ensure you pull all the latest changes before pushing your feature/bug fixes to the main branch. After resolving the conflicts, please open a new PR for review. Thank you!
@PriyaGhosal

I have noticed that the website is still in bad shape, even after I've made improvements. Now, more people have raised the same issue. What should I do? Please assign me the task again and guide me through the steps I need to follow.

repo: PriyaGhosal/BuddyTrail


text:
Automated Greetings on Issue Raised

Is your feature request related to a problem? Please describe.
Contributors often lack immediate acknowledgment when they raise an issue in the project repository, leading to a sense of disconnection and uncertainty about whether their concern has been noticed.
Describe the solution you'd like
Implement an automated system that generates a friendly greeting message whenever a new issue is raised within the project repository, providing immediate acknowledgment to the contributor.
Additional context
This feature would enhance user experience by fostering a sense of inclusivity and responsiveness within the project community. It would ensure that contributors feel valued and engaged from the moment they raise an issue, ultimately contributing to a more positive and collaborative development environment.

@thevijayshankersharma this feature has been implemented, kindly raise another issue.

@Priyaaa1 I can make auto greeting on PR, or issue or PR closed. should i raise for them ?


text:
StartPlay: Kontakt zu Uni XYZ festhalten und herstellen

Auf der StartPlay hat sich ein Kontakt zu Frau XYZ von der Uni XYZ ergeben, die grobe Idee war eine gemeinsame Antragstellung im nächsten Freiraum (Verbundantrag).
Bitte das andere Projekt als "related project" festhalten und nach Möglichkeit den Kontakt herstellen. So ein Antrag dauert ...
TODO:

[ ] 1. Eintrag als "related project": URL, kurze Beschreibung (2..3 Sätze)
[ ] 2. Person recherchieren und kontaktieren

Das andere Projekt haben wir tatsächlich schon dokumentiert (Zufälle gibts).
In der App bin ich grade zu blöd den link zu finden, aber das hat @AKirsch1 im Dungeon repo festgehalten (escape room).

https://github.com/Programmiermethoden/Dungeon/blob/master/doc/related_work/digi_komp_ass_escape_room.md
Das müsste es sein

https://github.com/Programmiermethoden/Dungeon/blob/master/doc/related_work/digi_komp_ass_escape_room.md
Das müsste es sein

ja cool. dann bitte dort noch einen satz dazu, dass sich auf der startplay23 ein kontakt zu ... ergeben hat.

authors: AMatutat cagix

repo: Programmiermethoden/Dungeon


text:
[DSL-GAME] API zum laden von Entitäten

In der DSL wird ein Monster erstellt:

Texturen
Hit Points
Auswahl aus vorgegeben Movementverhalten

das muss dann in das Spiel geladen werden.

Für die Verwendung von Java-Klassen aus der DSL sind zwei Dinge notwendig:

Übergang von Java-Klassen des Dungeon-Frameworks ins DSL-Typsystem (bspw. um Entitäten mit Komponenten zu definieren)
Übergang von DSL-Typen in Java-Klassen des Dungeon-Frameworks (um die in der DSL konfigurierten Entitäten & Komponenten im Spiel zu verwenden)

Übergang Java -> DSL
Aktuell können per @DSLType-Annotation markierte Klassen und Records als DSL-Typen in das Typsystem geladen werden. Alle Klassenmember, die auch Teil des entsprechenden DSL-Typen sein sollen müssen mit @DSLTypeMember markiert werden.
Der Name der Member wird zur Verwendung in der DSL in snake_case konvertiert, um einheitliche Namen in der DSL zur Verfügung zu stellen.
Beispiel
@DSLType
public class MyClassComponent {
    @DSLTypeMember
    private int member1;
    @DSLTypeMember
    private String member2;
}

@DSLType
public record MyRecordComponent(
    @DSLTypeMember int member3,
    @DSLTypeMember String member4
) {}

Die oben definierten Komponenten können dann in der DSL wie folgt verwendet werden, um ein Game-Object zu definieren:
// ...
game_object my_game_object {
    my_class_component {
        member1: 42,
        member2: "Hello, World!"
    },
    my_record_component {
        member3: 314,
        member4: "Moin"
    }
}
// ...

Übergang DSL -> Java
Soll eine in der DSL definierte Entität im Dungeon instanziiert werden, müssen aus den Werten, die die DSL-Objekte gespeichert haben, Instanzen der Java-Klassen, aus denen ursprünglich der DSL-Typ erzeugt wurde, erstellt werden. Also für das obere Beispiel würde zuerst eine Entität erstellt werden, in die dann die Komponenten MyClassComponent und MyRecordComponent mit entsprechend der DSL konfigurierten Werten hinzugefügt werden.
Um diesen Schritt nicht für jede neue Komponente händisch implementieren zu müssen, soll hierzu Reflection verwendet werden. Der TypeInstantiator (aktuell in diesem branch)
erstellt per Reflektion eine Instanz der ursprünglichen Java-Klasse (oder des Records). Hierbei gibt es einige Einschränkungen:

Der Konstruktor eines records hat als Parameter alle Member des Records. Der TypeInstantiator muss bei dem Konstruktor-Aufruf alle Member des records in korrekter Reihenfolge übergeben. Daher müssen alle Member des records mit @DSLTypeMember markiert werden.
Für Klassen erstellt der TypeInstantiator eine neue Instanz per Defaultkonstruktor und setzt die Fields der Klasse nachher per Reflection. Daher muss eine Klasse, die mit DSLType markiert ist, einen Defaultkonstruktor mit 0 Parametern haben, bzw. für bestimmte Anwendungsfälle (wie z.B. Komponenten, die immer einen entity-Parameter haben) genau definiert sein, welche Parameter wie an den Konstruktor übergeben werden müssen. Dafür ist allerdings aktuell noch kein Mechanismus vorhanden, der muss noch gebaut werden (@AMatutat ).

authors: AMatutat malt-r


text:
typo fix in segresnet2d

typo fix in segresnet2d

cc @myron

repo: Project-MONAI/research-contributions


text:
automate the testing of the jupyter notebooks

this ticket looks for an automated CI setup to ensure the quality of the notebooks.
see also discussions:

https://github.com/Project-MONAI/MONAI/issues/894
https://github.com/Project-MONAI/MONAI/issues/872
https://github.com/Project-MONAI/MONAI/issues/296
https://github.com/Project-MONAI/MONAI/issues/894#issuecomment-672934517

#107 provides preliminary support for this feature

#107 provides preliminary support for this feature

repo: Project-MONAI/tutorials


text:
missing translation (ferry)

Ticket from @mtmail
Going Newhaven, England to Dierre, France includes a ferry.
http://www.openstreetmap.org/directions?engine=osrm_car&route=50.7887%2C0.0484%3B49.9246%2C1.0791#map=9/50.3639/0.5672&layers=C
Step 17 shows [missing "en-US.javascripts.directions.instructions.ferry_without_exit" translation]
I checked theopenstreetmap-website, osrm-backend and osrm-frontend sources and can't find where that would go.

OSM Website does this. Closing here.
See e.g. https://github.com/openstreetmap/openstreetmap-website/issues/1369.

authors: daniel-j-h danpat

repo: Project-OSRM/osrm-frontend


text:
Cookbook currently not building

There are a few issues keeping this cookbook from building properly in the gallery, which can be seen in the build logs. To summarize, there is an error running the following cell in surface_currents.ipynb:
%run ./surface_currents_prep.ipynb

Exception: File `'./surface_currents_prep.ipynb.py'` not found.

And in surface_currents_model.ipynb:
NameError                                 Traceback (most recent call last)
/tmp/ipykernel_159/99668342.py in <module>
----> 1 class LossHistory(tf.keras.callbacks.Callback):
      2     def __init__(self, frequency=30):
      3         self.frequency = frequency
      4         self.batch_counter = 0
      5

NameError: name 'tf' is not defined

I noticed three copies of the main surface_currents.ipynb notebook, one in the root of the repo, one in /notebooks, and one in /notebooks/images. The Cookbook Actions are trying to run all of them, so that might be part of the issue.
There might be a problem with binderbot and %run, but I'm not familiar enough with either. There is some more discussion at #4 about data access.

I noticed three copies of the main surface_currents.ipynb notebook, one in the root of the repo, one in /notebooks, and one in /notebooks/images. The Cookbook Actions are trying to run all of them, so that might be part of the issue.

There definitely shouldn't be multiple copies, that's probably a mistake on my end. The correct versions are in /notebooks.

There might be a problem with binderbot and %run, but I'm not familiar enough with either. There is some more discussion at #4 about data access.

I think the rest of it has something to do with %run. Basically, the other two notebooks are just there so the functionality doesn't need to be inlined. It's quite a lot of code that's not really relevant to this Pythia cookbook, but I wanted to include them as notebooks for annotation purposes if anyone was curious.

I've also been getting this thing, which is a mystery to me:
Exception: File `'./surface_currents_prep.ipynb.py'` not found.

It's running it from the repo root directory, so you will need to add notebooks/ to that path

To be clearer, I'm not sure why it's appending .py to the filename.

You mean %run ./notebooks/surface_currents_prep.ipynb right?
Why is .py being appended here?

I just opened a PR that runs the notebook on GitHub instead of BinderHub. You can see the preview here. It looks like it was able to run the other notebook fine, but it just got caught on the data access (#4).

Sounds good. Is there a standard place to put data for cookbooks? I can add a subset of the original, I think it comes out to about a gig total.

I think 1 GB would probably be a problem, but at least 2 cookbooks do use some data stored in a folder in the repo (Gridding and Landsat ML, <50 MB). Is it possible that the CMIP6 or CESM LENS data could be used to show your workflow? Another option is to just display the pre-executed notebook while the data access is being figured out.

A related discussion about data storage for cookbooks is here: https://github.com/ProjectPythia/kerchunk-cookbook/issues/20

I asked Ryan about this and for this particular case, he said we make it host-pays, but I'm not sure what the current status is.


text:
Voucher of duplicate is displayed as registered but he is removed

Describe the Bug
This profile https://app.proofofhumanity.id/profile/0x5cf395b4d5c6bbc44bd26b387f582f10646f76ec was removed, because he vouched a profile which was removed with the Duplicate reason. However, the UI is displaying him as registered.
To Reproduce
It should happen the same to this one in a few hours https://app.proofofhumanity.id/profile/0xe30b1c351836ea35d7211734faa2b4c3254435e0.
My guess is that the problem is here. This callback is probably called AFTER this other callback is called, but it should be the other way around. The consequence of this is that this evaluates to false and the following 3 lines never get executed. I haven't implemented nor tested a fix so I don't know for sure.

On it! Thanks.

repo: Proof-Of-Humanity/proof-of-humanity-web


text:
unable to read node_modules/pt.blobjs

Which browser (+ version) ? Chrome / Firefox / Safari / Opera
Which OS (+ version)? Mac OS
Which layout mode? Column mode / Row mode
Which threading mode? Conversation mode / Message mode
Can you reproduce the problem each time? Yes
Which url?

What steps will reproduce the problem?

git pull

npm install

npm start

What is the expected result?
it should be working?
What happens instead?
does not work;
> protonmail-web@3.11.5 start /path/to/WebClient
> grunt watch --api=dev

Running "notify_hooks" task

Running "ngconstant:dev" (ngconstant) task
Creating module proton.config at src/app/config.js...OK

Running "clean:build" (clean) task
>> 1 path cleaned.

Running "html2js:app" (html2js) task
Successfully converted 231 html templates to js.

Running "sass:build" (sass) task

Running "concat:build_css" (concat) task

Running "postcss:dist" (postcss) task
>> 2 processed stylesheets created.

Running "copy:build_app_assets" (copy) task
Created 16 directories, copied 142 files

Running "copy:build_appjs" (copy) task
Copied 545 files

Running "concat:build_js" (concat) task

Running "copy:build_vendorjs" (copy) task
Warning: Unable to read "node_modules/pt.blobjs/Blob.js" file (Error code: ENOENT). Use --force to continue.

Please provide any additional information below. Attach a screenshot if possible.
I check the pt.blobjs in node_modules, there is no module directory there. There is nothing on package.json about it either. So it is missing somewhere somehow. Maybe we don't even need it but what should I do?

Hey,
we install this dep via the script 'tasks/privateDependencies.sh'.  I had the same issue this afternoon, after another $ npm i it worked.

We run the shell script via postinstall.

Can you try to re-run $ npm i ?

I have just tried both npm i and sudo npm i, still same.

Can you give me your npm.log ? You should see something inside the output from $ npm i.

do you mean debug log?
0 info it worked if it ends with ok
1 verbose cli [ '/usr/local/Cellar/node/8.1.3/bin/node',
1 verbose cli   '/usr/local/bin/npm',
1 verbose cli   'start' ]
2 info using npm@5.4.1
3 info using node@v8.1.3
4 verbose run-script [ 'prestart', 'start', 'poststart' ]
5 info lifecycle protonmail-web@3.11.5~prestart: protonmail-web@3.11.5
6 info lifecycle protonmail-web@3.11.5~start: protonmail-web@3.11.5
7 verbose lifecycle protonmail-web@3.11.5~start: unsafe-perm in lifecycle true
8 verbose lifecycle protonmail-web@3.11.5~start: PATH: /usr/local/lib/node_modules/npm/bin/node-gyp-bin:/path/to/WebClient/node_modules/.bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/Cellar/maven/3.5.0/libexec/bin
9 verbose lifecycle protonmail-web@3.11.5~start: CWD: /path/to/WebClient
10 silly lifecycle protonmail-web@3.11.5~start: Args: [ '-c', 'grunt watch --api=dev' ]
11 silly lifecycle protonmail-web@3.11.5~start: Returned: code: 3  signal: null
12 info lifecycle protonmail-web@3.11.5~start: Failed to exec start script
13 verbose stack Error: protonmail-web@3.11.5 start: `grunt watch --api=dev`
13 verbose stack Exit status 3
13 verbose stack     at EventEmitter.<anonymous> (/usr/local/lib/node_modules/npm/node_modules/npm-lifecycle/index.js:280:16)
13 verbose stack     at emitTwo (events.js:125:13)
13 verbose stack     at EventEmitter.emit (events.js:213:7)
13 verbose stack     at ChildProcess.<anonymous> (/usr/local/lib/node_modules/npm/node_modules/npm-lifecycle/lib/spawn.js:55:14)
13 verbose stack     at emitTwo (events.js:125:13)
13 verbose stack     at ChildProcess.emit (events.js:213:7)
13 verbose stack     at maybeClose (internal/child_process.js:897:16)
13 verbose stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:208:5)
14 verbose pkgid protonmail-web@3.11.5
15 verbose cwd /Users/yasin/dev/WebClient
16 verbose Darwin 16.7.0
17 verbose argv "/usr/local/Cellar/node/8.1.3/bin/node" "/usr/local/bin/npm" "start"
18 verbose node v8.1.3
19 verbose npm  v5.4.1
20 error code ELIFECYCLE
21 error errno 3
22 error protonmail-web@3.11.5 start: `grunt watch --api=dev`
22 error Exit status 3
23 error Failed at the protonmail-web@3.11.5 start script.
23 error This is probably not a problem with npm. There is likely additional logging output above.
24 verbose exit [ 3, true ]

Nope what's inside the $ npm i.
Cf the output from $ npm i.
$ npm i

> node-sass@4.5.3 install /home/dhoko/dev/taf/Angular/node_modules/node-sass
> node scripts/install.js

Cached binary found at /home/dhoko/.npm/node-sass/4.5.3/linux-x64-57_binding.node

> phantomjs-prebuilt@2.1.14 install /home/dhoko/dev/taf/Angular/node_modules/phantomjs-prebuilt
> node install.js

PhantomJS not found on PATH
Downloading https://github.com/Medium/phantomjs/releases/download/v2.1.1/phantomjs-2.1.1-linux-x86_64.tar.
bz2
Saving to /tmp/phantomjs/phantomjs-2.1.1-linux-x86_64.tar.bz2
Receiving...
  [======----------------------------------] 16%
Received 22866K total.
Extracting tar contents (via spawned process)
Removing /home/dhoko/dev/taf/Angular/node_modules/phantomjs-prebuilt/lib/phantom
Copying extracted folder /tmp/phantomjs/phantomjs-2.1.1-linux-x86_64.tar.bz2-extract-1509696813926/phantom
js-2.1.1-linux-x86_64 -> /home/dhoko/dev/taf/Angular/node_modules/phantomjs-prebuilt/lib/phantom
Writing location.js file
Done. Phantomjs binary available at /home/dhoko/dev/taf/Angular/node_modules/phantomjs-prebuilt/lib/phanto
m/bin/phantomjs

> node-sass@4.5.3 postinstall /home/dhoko/dev/taf/Angular/node_modules/node-sass
> node scripts/build.js

Binary found at /home/dhoko/dev/taf/Angular/node_modules/node-sass/vendor/linux-x64-57/binding.node
Testing binary
Binary is fine

> protonmail-web@3.11.7 postinstall /home/dhoko/dev/taf/Angular
> ./tasks/privateDependencies.sh

Cloning into 'node_modules/pt.blobjs'...
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 5 (delta 0), reused 3 (delta 0), pack-reused 0
Receiving objects: 100% (5/5), done.
Note: checking out '079824b6c118fbcd0b99c561d57ad192d2c6619b'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at bfb14fd... Bump v0.0.11
/home/dhoko/dev/taf/Angular
Cloning into 'node_modules/pt.qrcodejs'...
remote: Counting objects: 12, done.
remote: Compressing objects: 100% (10/10), done.
remote: Total 12 (delta 1), reused 7 (delta 1), pack-reused 0
Receiving objects: 100% (12/12), 52.67 KiB | 0 bytes/s, done.
Resolving deltas: 100% (1/1), done.
Note: checking out '04f46c6a0708418cb7b96fc563eacae0fbf77674'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at 04f46c6... Merge pull request #63 from markvantilburg/patch-1
/home/dhoko/dev/taf/Angular

--- custom dependencies installed ---

added 1100 packages in 38.071s

What's inside your output after > ./tasks/privateDependencies.sh ?

I also encountered this problem, how to solve?

You can comment the git clone inside ./tasks/privateDependencies.sh and install the lib via npm install blobjs.
Then inside the file env/conf.build.js
- 'node_modules/pt.blobjs/Blob.js',
+ 'node_modules/blobjs/Blob.min.js',

It should work. The new version will be without a git clone, everything will come via npm.

@dhoko Yes, it work, we only need add small adjustments:
env/conf.build.js :
  /* 'node_modules/pt.qrcodejs/qrcode.js', */
  'node_modules/qrcode/build/qrcode.min.js',

  (...)

  /* 'node_modules/pt.asmcrypto.js/asmcrypto.js', */
  'node_modules/asmcrypto.js/asmcrypto.js',

$ npm install qrcode
$ npm install asmcrypto.js
Thank you.

All changes to perform before the new release.
package.json
+    "asmcrypto.js": "https://github.com:vibornoff/asmcrypto.js.git#bfb14fdb4cecebd1ae260ae78e3663b8273120e1",
+    "blob.js": "^1.0.1",
+    "qrcodejs2": "0.0.2",

privateDependencies.sh
DEST_MAILPARSER='node_modules/pt.mailparser'

# Remove previous version
rm -rf $DEST_MAILPARSER

mkdir $DEST_MAILPARSER
cp src/libraries/mailparser.js $DEST_MAILPARSER/mailparser.js

echo
echo "--- custom dependencies installed ---"
echo

env/conf.build.js :
-      'node_modules/pt.blobjs/Blob.js',
+      'node_modules/blob.js/Blob.js',
-      'node_modules/pt.qrcodejs/qrcode.js',
+      'node_modules/qrcodejs2/qrcode.min.js',
-      'node_modules/pt.asmcrypto.js/asmcrypto.js',
+      'node_modules/asmcrypto.js/asmcrypto.js',

Voilà

cf https://github.com/ProtonMail/WebClient/blob/public/tasks/privateDependencies.sh
Voilà, everything is coming from npm and the package.json :)

authors: TangKunjun dhoko lacivert piotrm2011

repo: ProtonMail/WebClient


text:
Update README.md

I liked your idea of creating a repository with the existing projects in opensource respirators. I tried to collaborate by suggesting to include a project that I'm following from the Coronacirusmakers lab. Thanks!

Thanks!

authors: RobertLRead gpintarelli


text:
User registration

Endpoints:

Sign up for account

Triggers invitation email

Uses link in invitation email to complete registration
Models:
User model(s)

Update existing with fields we need
Create new models as necessary (preregistered user?)

AC:

Send new user payload to registration endpoint
Email address receives registration email
Clicking on link in email registers user
User is now listed on the home page (show that a user has been created)

A heads up that for the email sending portion of this, we are going to need to identify a Node.js/NestJS specific solution for sending email through Amazon SES with instance metadata provided credentials.
This can be done in a primitive way with the AWS SDK for JavaScript, but there may also be a good wrapper out there that integrates with NestJS.
I created https://github.com/PublicMapping/district-builder-2/issues/54 to account for the SES specific setup.

authors: hectcastro tgilcrest


text:
WebSocket disconnection should not be an error

In any of the following cases:

user loses Wi-Fi range
user puts his laptop to sleep/hibernation
server restarts
server stops

The users get's an alert about WebSocket disconnection:

This should not be an error because it is possible that the server was restarted but the session will be kept between the restarts. The next Puppet operation should try to reconnect to WebSocket or use HTTP fallback.

@miyconst after doing current work, could you investigate this and propose changes?

Me and @warpech on skype call agreed to:

Disable the ugly error message.
Switch to http/json+patch if WebSocket connection drops.
Try to restore WebSocket connection in 5/10/20/40/80 seconds.
Display a small and not annoying icon when connection drops and hide the icon when connection restored.

I have played with restoring WS connection a little bit. Now facing such problem:

Client loads page.
Client establishes connection with server.
Client sends patch 1 to the server.
Server receives the patch and closes the connection (or connection drops).
Client establishes connection with server again.
Client sends patch 2 to the server.
Server responds with remote version 3, but client expects it to be 2, as patch 1 was sent, but not confirmed.

What to do in such situation? We may ask server whether the patch 1 was really received or may assume by version # that the patch was received.

Could you specify the versions that your are talking about in each step? - PuppetJS' local version == Server's remote vs. PuppetJS' remote version == Server's remote? (/_ClientVersion or /_ServerVersion$ )

1.1.  Out:
this.localVersion = 1;
this.remoteVersion = 1;

[{"op":"replace","path":"/_ver#c$","value":2},{"op":"test","path":"/_ver#s","value":1},{"op":"replace","path":"/workspaces/0/Images/CurrentPage/Images/Cancel$","value":1}]

1.2. In: none
this.localVersion = 2;
this.remoteVersion = 1;

2.1. Out:
this.localVersion = 2;
this.remoteVersion = 1;

[{"op":"replace","path":"/_ver#c$","value":3},{"op":"test","path":"/_ver#s","value":1},{"op":"replace","path":"/workspaces/0/Images/CurrentPage/Images/Save$","value":1}]

2.2. In:
this.localVersion = 3;
this.remoteVersion = 1;

[{"op":"replace","path":"/_ver#s","value":3},{"op":"test","path":"/_ver#c$","value":3},{"op":"replace","path":"/workspaces/0/Images/CurrentPage/Images/RedirectUrl$","value":"/images"}]

At this moment local remoteVersion is 1, but the one which come from the server is 3.

Ping @warpech and @tomalec.

So the connections gets closed after browser sent message, and after server received it, but before server responses to browser, and what is worse server did composed change to clients message, which was not send.
@chrhol chould you confirm, I would expect that server ma queue such pending change on server side, and either send it when reconnected, on will just send entire JSON to reset all versions

If it may help somehow:
void Handle(Input.Cancel Action) {
    WebSocket.Current.Disconnect();
}

This is how I close the connection on Cancel button press.

I rewrote Konstantin's problem including the version numbers, because I couldn't put my head around it:

Client loads page (_ver#c$: 0, _ver#s: 0)
Client establishes connection with server
Client sends patch 1 to the server  (_ver#c$: 1, _ver#s: 0)
Server receives the patch and closes the connection (or connection drops).
Client establishes connection with server again.
Client sends patch 2 to the server   (_ver#c$: 2, _ver#s: 0)
Server responds with (_ver#c$: 2, _ver#s: 2), but client still waits for _ver#s: 1. In result, client hangs indefinitely

A naive solution would be to time out and create a new request for the missing patch or just the current viewmodel.
But maybe there could be some pure-OT solution?

Only one correction:
7. Client does not hand, it throws an exception.

What is the exception message?

Pure OT solution would be that server responds with {op: "replace", path: "_ver#s", value: "1"} at 7.

Why? Because in step 6 the client said that it knows _ver#s: 0?

What is the exception message?

My bad, it actually hangs, the exception occurs if the received patch was already applied.

@warpech  because versions should be increased consecutively, and I se no {op: "replace", path: "_ver#s", value: "1"} in this flow.

I think that in Konstantin's case it is true that server closed the connection imperatively, which means that it SHOULD push the pending _ver#s: 1 patch before disconnection. If it doesn't do that then it is an error.
But what in case when the server increased _ver#s to 1, but that patch never reached the client, because it was eaten by the gateway, middleware, etc. How could we recover from that?

But what in case when the server increased _ver#s to 1, but that patch never reached the client, because it was eaten by the gateway, middleware, etc. How could we recover from that?

This is a good point. I think the client, when reconnecting, either need to ask the server for all patches from a version or just asks for the whole viewmodel. for the first option, we need to save all patches that the client have not confirmed that it have received.

the client, when reconnecting, either need to ask the server for all patches from a version or just asks for the whole viewmodel. for the first option, we need to save all patches that the client have not confirmed that it have received.

Totally agreed, as I mentioned, JSON Patch OT Agent  keeps a list of "pending" patches - patches that were send to the remote, but remote didn't confirm it get them.
So I would say that both peers should send such info to each other when re-connecting.

But what in case when the server increased _ver#s to 1, but that patch never reached the client, because it was eaten by the gateway, middleware, etc. How could we recover from that?

I don't think PuppetJs should solve the problem of someone filtering, and eating messages during communication.
Our working scenarios are:
A

client sends a patch that triggers a change on server,
server increases _ver#s to 1, and sends it to client,
server closes connection,
once connection is re-opened (server may return view-model with _ver#s==1),
if a change is made on server-side, server increases _ver#s to 2, and sends it to client.

B

client sends a patch that triggers a change on server,
server closes connection, and no change was made,
once connection is re-opened (server may return view-model with _ver#s==1),
if a change is made on server-side, server increases _ver#s to 1, and sends it to client.

I don't think PuppetJs should solve the problem of someone filtering, and eating messages during communication also.

So you say PuppetJs should not solve the problem but actually in C you propose a solution :) Or is it incomplete?
A problem that I see with point C7 is currently we treat is as an error: https://github.com/PuppetJs/JSON-Patch-Queue/blob/gh-pages/src/json-patch-queue.js#L61. We can change it to be a warning.

in C you propose a solution :) Or is it incomplete?
Yes i do. But this is not a solution for all missing messages, only for re-sending pending messages, so somehow extending existing feature.

It will not send an error for C7 as patches 1 and 4 are processed on server, but you are right if we have PuppetJS, and JSON-Patch-OT-agent.js working on server as well, it will be an error, as 1 was already applied, in such case we should make it as warning, and disregard the patch 1, and apply 4.

Anything new in this issue? What is the priority?

Discussion about session reconnection is moved to another issue. Thanks for fixing the issue in topic!

authors: chrhol miyconst tomalec warpech

repo: PuppetJs/PuppetJs


text:
Very serious bug: Code not found.

Where's the code?

Sorry for late reply. Now we upload the code.

authors: PuzoW myermo

repo: PuzoW/One-Class-One-Click


text:
Update iis_helper_plugin.py

Strings of function RVAs/names may appear outside of vftables. In such cases, get_qword will return a value that is not a function/part of a function. Further code will then crash the plugin (as NoneType does not implement the method startswith).

Thanks for flagging this @jk45054 , and apologies for taking a while to respond to this! I've just pushed a reasonably big update to the code, which adds some error handling around these issues, so I'm going to close this PR off.

repo: PwCUK-CTO/iis-helper-plugin


text:
keyboard shortcut for lock screen

Win+L
syntax taken from here:
defaults write com.apple.Mail NSUserKeyEquivalents -dict-add "New Message" "@m"
gotta figure out what to replace "New Message" with

command line for mapping to a keybinding: https://best-mac-tips.com/2012/08/29/remapping-os-x-application-keyboard-shortcuts/
still looking for the actual command

this page says it's just "Lock Screen"

repo: PwshKen/dotfiles


text:
🛑 ArchiveBox is down

In 3c5d678, ArchiveBox (https://archivebox.pxlbuzzard.com) was down:

HTTP code: 500
Response time: 282 ms

Resolved: ArchiveBox is back up in 1db3f57.

repo: PxlBuzzard/upptime


text:
Issue with server listening on IPv6

Here is the issue i can run on specific IPv4 & IPv6 and it will work (for example: ./pykms_Server.py ::1 1688 - will listen on loopback interface ip v6 ::1 and ./pykms_Server.py 127.0.0.1 1688 - will listen on loopback interface ip v4 127.0.0.1), but as it stands right now there is no way to use both at the same time (dual stack), because for IP it only takes only 1 argument. Also default option (0.0.0.0), only listens on all interfaces IPv4 only and skips IPv6 listening... sure i could run 2 pykms_Server instances both listening on different ips, but it shouldnt be that hard, also since i run py-kms in docker, i would need to run 2 py-kms docker containers or write my own...
Would be nice to have ability, to set server to listen on multiple ips in the same instance and have default option to listen on all ipv4 and ipv6 addresses on all interfaces.

Actually its possible to specify more ips... something along this lines:
./pykms_Server.py 84.xxx.xxx.xxx 1688 -l 1033 -c 26 -a 120 -r 10080 -w RANDOM -V INFO -F STDOUT connect -n 10.0.0.1,1688 -n 2a01:xxx:xxxx:xxxx::1,1688,
bit clumsy :) now need to figure out how to add this in to docker without rebuilding it...

cc @simonmicro

Tried to "extend" docker LOGFILE env variable with -e LOGFILE="STDOUT connect -n 10.0.0.1,1688 -n 2a01:xxx:xxxx:xxxx::1,1688", but it errors out with: argument -F/--logfile: invalid directory: 'STDOUT connect -n 10.0.0.1,1688 -n 2a01:xxx:xxxx:xxxx::1,1688'. Exiting...
hm... dont think its possible how docker container is set right now, i think we would need another env variable for example "CUSTOM_OPTIONS" that would append whatever you put in to it at the end of pykms_Server.py command...

I dont understand, i created new env variable for docker, changed start.py to add connect that enviroment variable at the end (like i had it working outside docker container) and now im getting this error:
Sun, 03 Apr 2022 17:03:39 INFO     Log level: DEBUG
Sun, 03 Apr 2022 17:03:39 INFO     Setting gid to '65534'.
Sun, 03 Apr 2022 17:03:39 INFO     Setting uid to '65534'.
Sun, 03 Apr 2022 17:03:39 DEBUG    server_cmd: /usr/bin/python3 -u pykms_Server.py 84.xxx.xxx.xxx 1688 -l 1033 -c 26 -a 120 -r 10080 -w RANDOM -V DEBUG -F STDOUT connect -n 10.0.0.1,1688 -n 2a01:xxx:xxxx:xxxx::1,1688
unrecognized optional connect arguments: -n 10.0.0.1,1688 -n 2a01:260:4085:1000::1,1688. Exiting...
obviously server_cmd seems fine, i dont undestand why its working outside docker container in my python enviroment, but inside it errors out...
This is outside docker in my own python env:
mih ~/py-kms/py-kms # ./pykms_Server.py 84.xxx.xxx.xxx 1688 -l 1033 -c 26 -a 120 -r 10080 -w RANDOM -V INFO -F STDOUT connect -n 10.0.0.1,1688 -n 2a01:xxx:xxxx:xxxx::1,1688
Sun, 03 Apr 2022 17:09:54 INFO     TCP server listening at 84.xxx.xxx.xxx on port 1688
at 10.0.0.1 on port 1688
at 2a01:xxx:xxxx:xxxx::1 on port 1688
Sun, 03 Apr 2022 17:09:54 INFO     HWID: 86C01601ECD24FE
someone smarter then mee needs to figure this out :)

Hi,

Docker creates an isolated network namespace for every container. Please take a look into that (tip: network_mode: host).
Linux allows an IPv4 to connect to any IPv6 port thanks to address mapping / translation. Go ahead and test it! -> Meaning listening to :: should be enough.
For specific network restrictions please utilize the firewall capabilities of your setup (e.g. iptables for Linux).

Greetings...

Hey,

I know, im using host
yes if you set as IP :: server listens for traffic on all ipv6 interfaces, but not on ipv4 again problem is you would need to set 0.0.0.0 and ::

anyway i had some time, so i lerned some basic python, didnt go that far to change pykms_Server code but i fixed start.py to allow multiple IPs in docker eviroment variable: #238af40309f141d385517c76f2ab4503d29849ab

authors: Matthew-Beckett SoLoR1 simonmicro

repo: Py-KMS-Organization/py-kms


text:
Missing file

In the example at https://github.com/PyAV-Org/PyAV/blob/main/examples/subtitles/remux.py the file  webvtt.mkv is not found. No mention where to find it either. How can this script run? What does this file contain? Why is it used?
What's with you people? Why such a  sloppiness? What's the meaning or usefulness of publishing a non-runnable code from which also vital documentation/information is missing?

The resources/webvtt.mkv is a stand-in for any mkv file with a webvtt subtitle stream. Since this is an example file, and not library or testing code, an actual webvtt.mkv is not provided. Please keep it civil when discussing the project.

Thank you for your reply. How could I --or someone else--  one know this about this 'resources/webvtt.mkv' stuff? Really, think about it: Because the coder knows about it, it doesn't mean that everyone else knows too. What does it cost to the coder to write a short comment about it? So, is it me who must apologize for my "uncivil" message, in which all the questions in it are valid?
BTW, this is not lack of civileness. I didn't talk badly. It is a protest coming from my long experience with coders' and documenters' repetitive sloppiness. I am a progammer, coder and documenter and when I post any code in the Web I always use comments, even for things that are much more obvious than the above case. Ask me why.
(Note: Before this post, I used a civil "please", but it did not have any effect. I didn't reveive any reply.  My (superficial) "uncivileness" though had an effect.  Thank you.)

Regardless of "correctness", such provocative and emotional language (in both this issue and the first) directed at a contributor is not acceptable. If it was directed at a random person, you would have already been banned.

I undestand what you say and I respect it. (Well, to a certain point, of course. E.g. I can't take "banning" seriously in the specific case.)
But what amazes me however is that you didn't addreess --on a second plane-- any of the problems I mentioned and whether I was right or wrong.
Consider also that this same code has a real bug that I reported in a next Issue that I submitted and which you didn't even deign to address it all. Really What you could you expect from me to say about all that?
BTW, being a contributor --I am one myself in varilous forums and communities-- does not mean that you can post problematic code and/or not expect or even ignore problems that users are reporting.
In my experience, normally programmers thank users for reporting problems because only in that way they can correct them and become better themselves. You, instead, are annoyed.
I hope that someday all I'm trying to communicate to you in here will be very clear and real to you. Have a nice day.

authors: AlkisPis WyattBlue

repo: PyAV-Org/PyAV


text:
Add new plugin to check use of pyghmi

This patch set adds a new bandit plugin to check the use of pyghmi.
Closes #356
Signed-off-by: Tin Lam tin@irrational.io

Created a better PR in #803

repo: PyCQA/bandit


text:
Hybrid flow shop example

This PR adds an example for the hybrid flow shop problem. Part of #63.

RTD got confused because I switched this project to the PyJobShop organization but here is the RTD build: https://pyjobshop--108.org.readthedocs.build/en/108/index.html

Replaced by #110.

repo: PyJobShop/PyJobShop