fix: use domain-specific variable for WORKDIR
Avoid rm -rf
'ing some poor soul's $WORKDIR again.
Merge request reports
Activity
mentioned in issue #219 (closed)
- Resolved by Daniel M. Capella
added 5 commits
-
23ff7952...01b6b084 - 4 commits from branch
archlinux:master
- 779a032f - fix: use domain-specific variable for WORKDIR
-
23ff7952...01b6b084 - 4 commits from branch
added 1 commit
- 897a26dc - fix: use domain-specific variable for WORKDIR
assigned to @gromit
requested review from @gromit
changed milestone to %v1.2.0
added scopebug statusin-review labels
@polyzen I've added another variable refactoring, could you maybe have a look at that aswell?
added 5 commits
-
295d3ccb...05bea3e9 - 3 commits from branch
archlinux:master
- 12e2e801 - fix: use domain-specific variable for $WORKDIR
- 34f2cae7 - fix: use domain-specific variable for $TEMPDIR
-
295d3ccb...05bea3e9 - 3 commits from branch
- Resolved by Christian Heusel
@polyzen great, thank you for helping out here :) I'm wondering if a much simpler and less intrusive way would be to simply call `unset WORKDIR` before the declaration of
setup_workdir
which would effectively provide the same safety with a single line, plus on top even ensure it can't be set by accident. Would that be fine for you?As far as I understand the execution environments, this is not actually true. If you run pkgctl it will spawn a completely independent bash process where environment variables are leaking into but not the readonly properties. It would be different if it's sourced, effectively running in the same execution environment, but when starting thought pkgctl it won't be readonly anymore.
mentioned in merge request !247
changed milestone to %v1.2.1
mentioned in merge request !267 (merged)