jiebi/CodeConvo huggingface dataset:
Change:
Describe the bug Opening magnet links in Chromium fails and so does opening links in Discord when I'm using Sway. To Reproduce Steps to reproduce the behavior: to piratebay. using a magnet link. Discord. a link. Expected behavior When I use a magnet link to download torrent I expect it to open my torrent client (qbittorrent). In Discord clicking on links should open in Chromium. Screenshots Clicking on the open button doesn't do the thing. Additional context I only tried in Sway among the wayland compositors. X11 is fine. I haven't tried in Gnome wayland. The same might be the case with other electron apps. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Give advice if you know whom I should xdg_utils: Chromium: Discord: Metadata Maintainer information:
Have you tried configuring xdg using ?
Another possible option is that something like isn't set correctly within the sway context, so it doesn't find the correct settings
could you give (doesn't require rebuilding Chromium, only the wrapper) a test without xdg_utils installed globally?
I'm not sure how to do it, although is true by default, xdg tools are not available on PATH when I use sway unlike on for say bspwm.
Setting didn't help.
I'm currently rebuilding Chromium with , how do I avoid the full rebuild?
you can only avoid it if hydra populated the binary cache for you. You most likely CANT avoid it in this situation.
that's gonna take like 6 hours
I haven't had an issue with x11, so i changed your title
Just finished compiling, idd it works. On the other hand is it really a good solution?
FWIW, I use sway and have part of my user's packages and never had any issues with this, magnet links, mailto etc. links work just fine in Firefox, Chromium and everywhere else.
Next time you can try to e.g. cherry-pick the commit onto a channel like nixos-unstable. Should've mentioned that, sorry. In that case my branch was based on master the branch and the build on Hydra was still pending. I don't really see a problem with it. It is a bit strange/hacky but Chromium depends on these binaries and in such cases we usually prefix accordingly (see for other Nixpkgs examples, usually via ).
All the discussion here seems to be about chromium, was there a fix for discord? I am having the same problem
You can e.g. "fix" it by installing .

Discussion:
{ newScope, config, stdenv, fetchurl, makeWrapper <del> , llvmPackages_10, llvmPackages_11, ed, gnugrep, coreutils </del> <ins> , llvmPackages_10, llvmPackages_11, ed, gnugrep, coreutils, xdg_utils </ins> , glib, gtk3, gnome3, gsettings-desktop-schemas, gn, fetchgit , libva ? null , pipewire_0_2

export XDG_DATA_DIRS=$XDG_ICON_DIRS:$GSETTINGS_SCHEMAS_PATH''${XDG_DATA_DIRS:+:}$XDG_DATA_DIRS <ins> # Mainly for xdg-open but also other xdg-* tools: export PATH="${xdg_utils}/bin''${PATH:+:}$PATH" </ins> . w EOF
Change:
Project description " The Discord terminal client you never knew you wanted. " aka, a Discord CLI client. Metadata homepage URL: source URL: license: bsd3 platforms: linux

Discussion:
<ins> { stdenv, buildGoModule, fetchFromGitHub }: buildGoModule rec { pname = "cordless"; version = "2020-08-30"; src = fetchFromGitHub { owner = "Bios-Marcel"; repo = pname; rev = version; sha256 = "sha256-CwOI7Ah4+sxD9We+Va5a6jYat5mjOeBk2EsOfwskz6k="; }; subPackages = [ "." ]; vendorSha256 = "sha256-01I7GrZkaskuz20kVK2YwqvP7ViPMlQ3BFaoLHwgvOE="; meta = with stdenv.lib; { homepage = "https://github.com/Bios-Marcel/cordless"; description = "Discord terminal client"; license = licenses.bsd3; maintainers = with maintainers; [ colemickens ]; platforms = platforms.unix; }; } </ins>

convchain = callPackage ../tools/graphics/convchain {}; <ins> cordless = callPackage ../applications/networking/instant-messengers/cordless { }; </ins> coursera-dl = callPackage ../applications/misc/coursera-dl {}; coyim = callPackage ../applications/networking/instant-messengers/coyim {};
Change:
Describe the bug When trying to use this package, I'm getting: To Reproduce Additional context I'm currently disabling gst-rtsp-server's split outputs in order to actually use it. Notify maintainers Maintainer information:
We should probably apply
That patch won't apply. But I managed to apply a different fix based on a common fix to other gst plugins, at .

Discussion:
outputs = [ "out" "dev" ]; <ins> patches = [ # To use split outputs, we need this so double prefix won't be used in the # pkg-config files. Hopefully, this won't be needed on the next release, # _if_ # https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/merge_requests/1 # will be merged. For the current release, this merge request won't apply. ./fix_pkgconfig_includedir.patch ]; </ins> nativeBuildInputs = [ meson ninja

<ins> diff --git i/pkgconfig/meson.build w/pkgconfig/meson.build index 8ed8299..594cbfe 100644 --- i/pkgconfig/meson.build +++ w/pkgconfig/meson.build @@ -2,8 +2,8 @@ pkgconf = configuration_data() pkgconf.set('prefix', get_option('prefix')) pkgconf.set('exec_prefix', '${prefix}') -pkgconf.set('libdir', '${prefix}/@0@'.format(get_option('libdir'))) -pkgconf.set('includedir', '${prefix}/@0@'.format(get_option('includedir'))) +pkgconf.set('libdir', join_paths(get_option('prefix'), get_option('libdir'))) +pkgconf.set('includedir', join_paths(get_option('prefix'), get_option('includedir'))) pkgconf.set('GST_API_VERSION', api_version) pkgconf.set('VERSION', gst_version) </ins>
Change:
Describe the bug When building octave on Darwin, I found that dylib paths to suitesparse libraries embedded in the octave binary were just unqualified relative filenames, not absolute store paths, causing loading errors. To Reproduce Steps to reproduce the behavior: on Darwin with nixpkgs master the resulting binary using unqualified paths to various suitesparse libraries Expected behavior I believe this issue should be fixed by , which is referenced by suitesparse already. However there is a fix in place for a more specific issue (I believe dylib paths referencing the build dir) which seems to be shadowing the normal function: I worked round this by simply renaming the function (will make a PR), but it's possible there's a better fix. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata Please run and paste the result. Maintainer information:

Discussion:
"library" ]; <del> # Likely fixed after 5.7.2 # https://github.com/DrTimothyAldenDavis/SuiteSparse/commit/f6daae26ee391e475e2295e77c839aa7c1a8b784 postInstall = stdenv.lib.optionalString stdenv.isDarwin '' # The fixDarwinDylibNames in nixpkgs can't seem to fix all the libraries. # We manually fix them up here. fixDarwinDylibNames() { local flags=() local old_id for fn in "$@"; do flags+=(-change "$PWD/lib/$(basename "$fn")" "$fn") done for fn in "$@"; do if [ -L "$fn" ]; then continue; fi echo "$fn: fixing dylib" install_name_tool -id "$fn" "''${flags[@]}" "$fn" done } fixDarwinDylibNames $(find "$out" -name "*.dylib") ''; </del> meta = with stdenv.lib; { homepage = "http://faculty.cse.tamu.edu/davis/suitesparse.html"; description = "A suite of sparse matrix algorithms";
Change:
Describe the bug When running the program in a context where is not set up perfectly for nix usage, running fails to run, saying it can not count colors. To Reproduce Steps to reproduce the behavior: mosh in a "clean" env without any nix paths on it: that it's unable to exec : Expected behavior An attempt to connect to Additional context I suspect this could easily be fixed by making the wrapper that mosh installs prefix the mosh bin to . Notify maintainers Metadata Please run and paste the result. Maintainer information:
As a workaround, I currently run mosh like this in iTerm: That seems not ideal, but it works for now (:

Discussion:
patches = [ ./ssh_path.patch <ins> ./mosh-client_path.patch </ins> ./utempter_path.patch # Fix w/c++17, ::bind vs std::bind (fetchpatch {

postPatch = '' substituteInPlace scripts/mosh.pl  --subst-var-by ssh "${openssh}/bin/ssh" <ins> substituteInPlace scripts/mosh.pl  --subst-var-by mosh-client "$out/bin/mosh-client" </ins> ''; configureFlags = [ "--enable-completion" ] ++ lib.optional withUtempter "--with-utempter";

<ins> diff --git a/scripts/mosh.pl b/scripts/mosh.pl index 56e96d7..2a2177e 100755 --- a/scripts/mosh.pl +++ b/scripts/mosh.pl @@ -61,7 +61,7 @@ my $have_ipv6 = eval { $|=1; -my $client = 'mosh-client'; +my $client = '@mosh-client@'; my $server = 'mosh-server'; my $predict = undef; @@ -91,7 +91,7 @@ my @cmdline = @ARGV; my $usage = qq{Usage: $0 [options] [--] [user@]host [command...] --client=PATH        mosh client on local machine -                                (default: "mosh-client") +                                (default: "@mosh-client@") --server=COMMAND     mosh server on remote machine (default: "mosh-server") </ins>
Change:
I cannot install/build anything at this moment. A dir that is created, for example: Here's an example of a full dir structure I am on nix 1.10, nixpkgs commit-id , on the staging branch, as per the fix that was introduced for the permissions flags in . I am running OSX 10.11 public beta 6 (15A278b)
I'm running OSX 10.11 GM, using master with cherry-picked from staging, and I'm having the same problem with findutils. This is really bad. I can't even delete the affected build directory because the path is too long.
This does not appear to be related to . I just reproduced it running OS X 10.11 GM on master with reverted, and I'm running into the same problem, now with coreutils instead of findutils. It's possible this is a 10.11 bug.
Yep, same problem building findutils-4.4.2 from the tarball with Xcode tools. Many of the GNU utilities have an M4 macro that checks for getcwd problems during the configure process, and that's breaking. Anyway, this appears to be an upstream/vendor issue and not related to Nix.
I've filed a Radar with Apple. Here's the Open Radar.
As a workaround, you can skip the configure test that triggers the bug: export glcvfuncgetcwdabort_bug="no" I've hacked this into preHook in in my local tree.
Thanks a lot. I'll try this straight away.
How to remove ?
I've tried all the command-line tricks I know and I still haven't been able to delete it. No word from Apple on my Radar submission, either, unfortunately.
Holy...I got the same deep directory when trying to bootstrap a Gentoo Prefix...
Finally find the solution:
Can anyone confirm this issue still exists?
I believe it was fixed in one of the El Cap updates. I haven't experienced it building Nix on Darwin recently.

Discussion:
<del> { stdenv, fetchurl, python, utillinux, openssl, http-parser, zlib, libuv }: </del> <ins> { stdenv, fetchurl, python, utillinux, openssl_1_0_2, http-parser, zlib, libuv }: </ins> let <del> version = "1.6.4"; </del> <ins> version = "2.1.0"; </ins> inherit (stdenv.lib) optional maintainers licenses platforms; in stdenv.mkDerivation { name = "iojs-${version}"; src = fetchurl { url = "https://iojs.org/dist/v${version}/iojs-v${version}.tar.gz"; <del> sha256 = "1qzvf7g457dppzxn23wppjcm09vh1n6bhsvz5szhwgjvl0iv2pc7"; </del> <ins> sha256 = "0v6jzsrq3ym0nqy7nb9chn8ij79agifwdvsp5nysgr609na7617i"; </ins> }; prePatch = ''

configureFlags = [ "--shared-openssl" "--shared-http-parser" "--shared-zlib" "--shared-libuv" ]; <del> buildInputs = [ python openssl http-parser zlib libuv ] ++ (optional stdenv.isLinux utillinux); </del> <ins> # iojs has --enable-static but no --disable-static. Automatically adding --disable-static # causes configure to fail, so don't add --disable-static. dontDisableStatic = true; buildInputs = [ python openssl_1_0_2 http-parser zlib libuv ] ++ (optional stdenv.isLinux utillinux); </ins> setupHook = ../nodejs/setup-hook.sh; passthru.interpreterName = "iojs";
Change:
Describe the bug Trying to build a Windows cross-compiler on Darwin fails at the build of mcfgthreads. To Reproduce On a Darwin host, macOS 10.15.6 (19G2021) in my case: Expected behavior The package should be built using a Windows cross-compiler. Additional context Compiling fails at the package. The phase runs through, but fails: This overlay fixes the problem for me: You can reproduce a successful build like this: However, I am uncertain, whether this is the proper fix or whether I should dig deeper to diagnose the root cause of this diagnostic. Notify maintainers (not listed as maintainer, but introduced and might know how to fix) Metadata system: host os: multi-user?: sandbox: version: channels(Michael): nixpkgs:
I also get this exact same bug. Any ideas on where to start looking?
I just opened pull request to suggest my fix. With this, I can build a Windows cross-compiler on Darwin.
But why does it happen on macos and not Linux? That would still be interesting to know. Someone suggested ASLR might have something to do with it?
It is a warning that happens with precompiled headers on macOS. I deduce from that expects its own text segment to be in the same location when it creates the precompiled header and when it uses it. This is not the case on macOS, due to aggressive ASLR. I think this leads to simply ignoring the precompiled header, which is not a problem. The problem only happens here, because the build system treats all warnings as hard errors. This is what my patch changes.
True, since it just skips using the pch it is not that bad :)

Discussion:
rm -r "$sourceRoot/debug" "$sourceRoot/release" ''; <ins> postPatch = '' substituteInPlace Makefile.am --replace '-Werror' '' ''; </ins> nativeBuildInputs = [ autoreconfHook ];
Change:
Describe the bug It is not possible to delete files in atom. To Reproduce Steps to reproduce the behavior: to delete a file Expected behavior This action should not result in an error. Notify maintainers Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
gvfs-trash has been removed for a few years () after several years of deprecation period. For the atom issue, this is likely a duplicate of
Ah thank you for this, I will update the title and description accordingly
You can try installing globally. That contains command, which is ’s successor and most programs support it. Not sure about Atom though.

Discussion:
<del> { lib, stdenv, pkgs, fetchurl, wrapGAppsHook, gvfs, gtk3, atomEnv }: </del> <ins> { lib, stdenv, pkgs, fetchurl, wrapGAppsHook, glib, gtk3, atomEnv }: </ins> let versions = {

preFixup = '' gappsWrapperArgs+=( <del> --prefix "PATH" : "${gvfs}/bin" </del> <ins> # needed for gio executable to be able to delete files --prefix "PATH" : "${glib.bin}/bin" </ins> ) '';
Change:
Describe the bug Example config gives me this . To Reproduce Steps to reproduce the behavior: your nixos-config while using nix flakes recursion Additional context Code in nixos
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
I think it's because of . This patch works, though I'm not sure how robust it is:
any chance this patch will be upstreamed?
Just for information to everyone who comes here because they try to create specialised configs in flakes, if you use (I did to inject home-manager) then it should be possible to replace it with an inline module like explained here: Using will result in an "attributes missing" error

Discussion:
let collected = collectModules (specialArgs.modulesPath or "") (modules ++ [ internalModule ]) <del> ({ inherit lib options config; } // specialArgs); </del> <ins> ({ inherit lib options config specialArgs; } // specialArgs); </ins> in mergeModules prefix (reverseList collected); options = merged.matchedOptions;

<del> { config, lib, pkgs, modules, baseModules, ... }: </del> <ins> { config, lib, pkgs, modules, baseModules, specialArgs, ... }: </ins> with lib;

# !!! fix this children = mapAttrs (childName: childConfig: (import ../../../lib/eval-config.nix { <del> inherit baseModules; </del> <ins> inherit baseModules specialArgs; </ins> system = config.nixpkgs.initialSystem; modules = (optionals childConfig.inheritParentConfig modules)
Change:
Describe the bug The build tool (part of texlive) can't be started. The Error says To Reproduce Steps to reproduce the behavior: -env -iA nixos.jdk11 Expected behavior Arara should start. Additional context The Problem is in the script (texlive-arara-) which wraps the java app. It should use to strip the suffix and start the , but does not use the required argument, so the script tries to start The Problem was fixed by upstream here: But it is still in the snapshots of texlive 2019 which nixpkgs uses. Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata system: host os: multi-user?: sandbox: version: channels(alwin): channels(root): nixpkgs: Maintainer information:

Discussion:
- source: ../../../../../doc/languages-frameworks/texlive.xml - current html: https://nixos.org/nixpkgs/manual/#sec-language-texlive */ <del> { stdenv, lib, fetchurl, runCommand, writeText, buildEnv </del> <ins> { stdenv, lib, fetchurl, fetchpatch, runCommand, writeText, buildEnv </ins> , callPackage, ghostscriptX, harfbuzz, poppler_min , makeWrapper, python, ruby, perl , useFixedHashes ? true

collection-plaingeneric = orig.collection-plaingeneric // { deps = orig.collection-plaingeneric.deps // { inherit (tl) xdvi; }; }; <ins> # TODO revert for texlive 2020 arara = lib.recursiveUpdate orig.arara { postUnpack = let arara_jar_fix = fetchpatch { url = "https://github.com/TeX-Live/texlive-source/commit/dbaf12f4a47dcd62bcc96346f65493fda3fec2c8.diff"; sha256 = "148knr8k6sm6fpyj31kdq85yxvzvwp1prjha3f07q24kbar2l830"; }; in '' if [ -f "$out"/scripts/arara/arara.sh ]; then cd "$out"/scripts/ patch -p4 <${arara_jar_fix} fi ''; }; </ins> }); # overrides # tl =

"adhocfilelist-2019"="l8ayz7mqaa5lma2bvqb2brc879y0viij"; "adhocfilelist.doc-2019"="gm20nhwq88s1cmch3pcgkqnyahb5gnri"; "adhocfilelist.source-2019"="3qx23im0z07cnk2bd5vrskl153zxy6ff"; <del> "arara-4.0.6"="qk5dq5f0il52m1gp8ckd7ilqbmpkvfmj"; </del> <ins> "arara-4.0.6"="6jhbdl9kh0d7iaq9qrl71kqzrmvvx9ya"; </ins> "arara.doc-4.0.6"="rvkrcair91scrk763igaj9mmi23n5j7x"; "arara.source-4.0.6"="s7rlspqx9dqsbixbnmnaz9hh7gwkmkfi"; "asymptote-2.49"="ka921kxzvyq3hi5frln4hh7qg1kfgch7";
Change:
Describe the bug The Emacs package is not properly installed at byte-compilation time, nor can it be easily installed during a live Emacs session. To Reproduce Using Nix, install the Melpa package alongside Emacs. Try to during an Emacs session. Expected behavior Either a prebuilt wrapper should get loaded, or we should be able to build it during an Emacs session. Additional context We presently can't build it live since the Nix store is read-only. Here's the backtrace: Metadata Please run and paste the result.

Discussion:
ivy-rtags = fix-rtags super.ivy-rtags; <ins> libgit = super.libgit.overrideAttrs(attrs: { nativeBuildInputs = (attrs.nativeBuildInputs or []) ++ [ pkgs.cmake ]; buildInputs = attrs.buildInputs ++ [ pkgs.libgit2 ]; dontUseCmakeBuildDir = true; postPatch = '' sed -i s/'add_subdirectory(libgit2)'// CMakeLists.txt ''; postBuild = '' pushd working/libgit make popd ''; postInstall = '' outd=$(echo $out/share/emacs/site-lisp/elpa/libgit-**) mkdir $outd/build install -m444 -t $outd/build ./source/src/libegit2.so rm -r $outd/src $outd/Makefile $outd/CMakeLists.txt ''; }); </ins> magit = super.magit.overrideAttrs (attrs: { # searches for Git at build time nativeBuildInputs =
Change:
Describe the bug Using sqlite as backend yields the following error How should sqlite be ? Should yarn be ran again? To Reproduce Notify maintainers Metadata Maintainer information:
I did some digging into why this does not work anymore and it seems that this probably did not work for a long time without anyone noticing (including me), even though this should have been caught by the test. The node module is built with using , but on startup I could see that node looks for the module with . Also according to node version 10 does not seem to be officially supported by . Adding.. ..directly after calling for does work, but I am pretty sure that this hack could have weird consequences during runtime :) Building codimd with node version 12, which is officially supported by sqlite3, is probably our best option here and I just successfully ran the test with it. I'll open a PR with the update later this evening. /cc
Working well now, thanks!

Discussion:
{ stdenv, fetchFromGitHub, fetchpatch, makeWrapper <del> , which, nodejs, mkYarnPackage, python2 }: </del> <ins> , which, nodejs, mkYarnPackage, python2, nixosTests }: </ins> mkYarnPackage rec { name = "codimd";

runHook postDist ''; <ins> passthru.tests = { inherit (nixosTests) codimd; }; </ins> meta = with stdenv.lib; { description = "Realtime collaborative markdown notes on all platforms"; license = licenses.agpl3;

cmt = callPackage ../applications/audio/cmt {}; codimd = callPackage ../servers/web-apps/codimd { <del> nodejs = nodejs-10_x; </del> <ins> nodejs = nodejs-12_x; </ins> }; colord = callPackage ../tools/misc/colord { };
Change:
Describe the bug To Reproduce Steps to reproduce the behavior: ~/nixpkgs -build -A lutris <details<summarylog</summary</detailsExpected behavior Screenshots Additional context Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
thanks !!

Discussion:
<del> { stdenv, fetchurl, texinfo, libXext, xorgproto, libX11 </del> <ins> { stdenv, fetchurl, texinfo6_5, libXext, xorgproto, libX11 </ins> , libXpm, libXt, libXcursor, alsaLib, cmake, zlib, libpng, libvorbis , libXxf86dga, libXxf86misc , libXxf86vm, openal, libGLU, libGL }:

]; buildInputs = [ <del> texinfo libXext xorgproto libX11 libXpm libXt libXcursor </del> <ins> texinfo6_5 libXext xorgproto libX11 libXpm libXt libXcursor </ins> alsaLib cmake zlib libpng libvorbis libXxf86dga libXxf86misc libXxf86vm openal libGLU libGL ];
Change:
Describe the bug To Reproduce Steps to reproduce the behavior: ~/nixpkgs -build -A tilix <details<summarylog</summary</detailsExpected behavior Screenshots Additional context Notify maintainers <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. -- Metadata system: host os: multi-user?: sandbox: version: channels(root): nixpkgs: Maintainer information:
build tilix
I guess that only works for PR. Sorry.
This looks like an issue with the package.
This probably needs patching
My mistake, the same error occurs in multiple tests, so fixing a single test won't do.
grepping for points to the DMD linker: It looks like the DMD linker invokes gcc with to do the actual work. Considering that the package hasn't been updated since April, perhaps some change in the gcc toolchain caused this build failure?
Pinging maintainers
output of <details
Thanks everyone

Discussion:
doCheck = true; <ins> # NOTE: Purity check is disabled for checkPhase because it doesn't fare well # with the DMD linker. See https://github.com/NixOS/nixpkgs/issues/97420 </ins> checkPhase = '' cd dmd <del> make -j$NIX_BUILD_CORES -C test -f Makefile PIC=1 CC=$CXX DMD=${pathToDmd} BUILD=release SHELL=$SHELL </del> <ins> NIX_ENFORCE_PURITY=  make -j$NIX_BUILD_CORES -C test -f Makefile PIC=1 CC=$CXX DMD=${pathToDmd} BUILD=release SHELL=$SHELL </ins> cd ../druntime <del> make -j$NIX_BUILD_CORES -f posix.mak unittest PIC=1 DMD=${pathToDmd} BUILD=release </del> <ins> NIX_ENFORCE_PURITY=  make -j$NIX_BUILD_CORES -f posix.mak unittest PIC=1 DMD=${pathToDmd} BUILD=release </ins> cd ../phobos <del> make -j$NIX_BUILD_CORES -f posix.mak unittest BUILD=release ENABLE_RELEASE=1 PIC=1 DMD=${pathToDmd} DFLAGS="-version=TZDatabaseDir -version=LibcurlPath -J$(pwd)" </del> <ins> NIX_ENFORCE_PURITY=  make -j$NIX_BUILD_CORES -f posix.mak unittest BUILD=release ENABLE_RELEASE=1 PIC=1 DMD=${pathToDmd} DFLAGS="-version=TZDatabaseDir -version=LibcurlPath -J$(pwd)" </ins> cd .. '';