This action is completely valid on both Windows and Linux (and OS X)
operating systems; tested with `mklink` and `ln -s` respectively.
Note that targets for hard links must exist, thus we check specifically
for symbolic links.
Both the path globber in session state and the `New-Item` implementation
needed to be fixed to allow the target not to exist.
Resolves#801.
Also enable symbolic link tests on Windows.
While Windows will automatically open a URL used as a process by
launching a browser, OS X needs to use `open <URL>`, and Linux needs to
use `xdg-open <URL>` (the most distribution-independent way).
Resolves#802.
The aliases which conflict with Linux native commands were consolidated
and removed with the pre-processor definition `LINUX`. Additionally,
several "conflicts" are purposefully kept and likewise consolidated.
They are kept because Bash itself stomps on the native commands with its
own built-ins, and so we're adopting the same behavior.
The `clear` and `more` aliases are edge cases where the functions they
call are already fixed for Linux, and so we keep these too.
Resolves#567.
So that the resource manager doesn't try to load a non-existent
satellite assembly (and thus throw).
The culture `en-US` is the default `CurrentCulture` on all platforms I
tested, specifically not `en`.
Note that there is a problem with the FullCLR build where some other
assembly is still attempting to reference `Logging.resources` instead of
`System.Management.Automation.Logging.resources`.
Specifically this enables us to leverage `dotnet-resgen` to
auto-generate the `resx` files into `resources` files for the default
culture, which are then compiled into the SMA assembly.
This requires a change to the C# bindings. The Windows build system
takes `file.resx` and compiles `file.resources`, but CLI prepends the
assembly name, thus compiling `SMA.file.resources`. So the resource
manager in the generated bindings must be adjusted to look for
`SMA.file` instead of `file`.
Note that C# bindings cannot yet be auto-generated.
Given localized resources of the form `file.en-US.resx`, `dotnet-resgen`
will create a satellite assembly and publish it to
`en-US/SMA.resources.dll`, so #666 will not be a technical problem.
The primary reason to do this is that the VS Code debugger is not
compatible with rc2.
Secondarily, we want to continue tracking CoreCLR/FX master branch,
which means to continue with the latest release candidates. Since we are
releasing in August, we will be able to pick up the converged RTM
version before release.
The only advantage of rc2 is that it is frozen; but we have this anyway
because we snap to particular builds.
All libraries now use the framework `netstandard1.5`, and import the
`dnxcore50` and `portable` frameworks. The app that is published,
Microsoft.PowerShell.Linux.Host, that is, the top-level dependency that
emits an executable, instead targets `netstandardapp1.5` and has a new
`runtimes` key so that .NET CLI's `restore` and `publish` commands know
which runtime implementations to resolve.
When switching to the new CLI, we needed to fix how we specified our
dependencies. In particular, the .NET CLI team helped me figure out how
to download packages that are reference assembly only on Linux, with
implementations on Windows. The result of this is the new `frameworks`
setup.
Additionally, we were incorrectly specifying our build dependencies;
that is, projects we also build (not packages). The solution was much
cleaner. We removed the `type: build` section and replaced it with the
version `1.0.0-*` that all our projects currently use.
The `project.json` files also had their names, descriptions,
indentation, and versions fixed.
The build scripts were simplified.
Andrew Schwartzmeyer