Fix install script to change directory before cleanup

[Sven Giermann (Giermann)]

Two related fixes in the Go feature's "install tools" block.

1. After installing the Go tools, the script never leaves ${GOPATH}
   (a temp dir, default /tmp/gotools) before removing it with
   rm -rf "${GOPATH}". The shell's cwd is left pointing at a deleted
   directory for the rest of the script. The two find calls that
   follow then fail while resolving their own initial working
   directory:

   find: Failed to save initial working directory: No such file or directory
   

   This is silent on filesystems/kernels where a process may keep
   using a cwd after it's been unlinked, but fails hard on at least
   some overlay2 configurations (reproduced on a Synology DSM host,
   kernel 4.4). Explicitly cd-ing to a directory that's guaranteed to
   still exist before the rm -rf makes this deterministic regardless
   of filesystem/kernel.

2. Because of (1), the piped xargs -n 1 -0 chmod g+s received empty
   input and (GNU xargs' documented default without -r) still ran
   chmod g+s once with no arguments:

   chmod: missing operand after 'g+s'
   

   Independently of fix (1), -r/--no-run-if-empty belongs on these
   invocations regardless: chmod should never be invoked at all when
   find legitimately produces no output.

[Kaniska (v-Kaniska244)]

Hi Sven Giermann (@Giermann)

Thank you for the contribution. Would it be possible to merge this change with the #1729 PR change as both are realted to the same go feature. Please let me know in case of any concern with that.

[Sven Giermann (Giermann)]

No concerns, in fact I fixed both at the same time at my side. But as it addresses different issues (buggy invokation of find vs. feature enhancement), separated them to address only one at a time.

It would be a 10 seconds task to include f400959 into #1729. Should I do this?

[Kaniska (v-Kaniska244)]

No concerns, in fact I fixed both at the same time at my side. But as it addresses different issues (buggy invokation of find vs. feature enhancement), separated them to address only one at a time.

It would be a 10 seconds task to include f400959 into #1729. Should I do this?

Hi Sven Giermann (@Giermann)

It should fine to merge this change along with the other PR #1729 , provided the other PR #1729 description is also updated with this change. This is considering that the fix in #1728 is in fact a simple one.