Failure to execute if directory is not named "kiauh" #194

New Issue

2022-04-29T03:48:31+02:00

compucat commented

2022-04-29 03:48:31 +02:00

(Migrated from github.com)

Linux Distribution

Distro-agnostic; tested on ubuntu groovy

What happened

KIAUH errors on line 14 if the working directory is not named "kiauh". This seems to be because SRCDIR is set as one directory above "kiauh", and line 14 appends "/kiauh/scripts" without verifying that the folder is indeed named "kiauh".

There are many reasons why this could be the case - for example, if a user downloads the source archive in ZIP format from GitHub (in which case the downloaded archive will extract to "kiauh-master").

What did you expect to happen

KIAUH should execute as long as the directory structure is intact, regardless of the name of the "kiauh" folder.

How to reproduce

Install KIAUH and verify that it is in a working state.

Rename the "kiauh" folder to something else (for example, "definitely-not-kiauh").

Attempt to run kiauh.sh.

Additional information

No response

### Linux Distribution Distro-agnostic; tested on ubuntu groovy ### What happened KIAUH errors on line 14 if the working directory is not named "kiauh". This seems to be because SRCDIR is set as one directory above "kiauh", and line 14 appends "/kiauh/scripts" without verifying that the folder is indeed named "kiauh". There are many reasons why this could be the case - for example, if a user downloads the source archive in ZIP format from GitHub (in which case the downloaded archive will extract to "kiauh-master"). ### What did you expect to happen KIAUH should execute as long as the directory structure is intact, regardless of the name of the "kiauh" folder. ### How to reproduce Install KIAUH and verify that it is in a working state. Rename the "kiauh" folder to something else (for example, "definitely-not-kiauh"). Attempt to run `kiauh.sh`. ### Additional information _No response_

carl1961 commented

2022-05-02 09:16:11 +02:00

(Migrated from github.com)

why would you do that? rename the folder, that would break the scripts that look for kiauh

dw-0 commented

2022-05-02 10:03:43 +02:00

(Migrated from github.com)

First of all i don't see this as a bug. It is the currently intended behavior. You do have a point in case someone downloads the sources as an archive, though this is not the recommended way and it contradicts the current installation instructions.
I don't see any other reasons or use cases why you have to rename the root folder, are there any? On the other hand i also don't see a particular downside to it.

I might consider improving that behavior with version 4 of KIAUH.

First of all i don't see this as a bug. It is the currently intended behavior. You **do** have a point in case someone downloads the sources as an archive, though this is not the recommended way and it contradicts the current installation instructions. I don't see any other reasons or use cases why you have to rename the root folder, are there any? On the other hand i also don't see a particular downside to it. I might consider improving that behavior with version 4 of KIAUH.

compucat commented

2022-05-09 19:54:20 +02:00

(Migrated from github.com)

Pardon the delayed response!

IMO it's bad practice to ambiguously crash depending on the name of the working directory, especially if the tool is intended to be installed in the user's home directory. By FHS, /home should only be used to store configuration data and a user's personal files. (FHS v2.3 formerly stated "Therefore, no program should rely on this location"; however, that was amended in 2015, and it can reasonably be assumed that /home is safe to store user-specific config files.)

I see a couple of alternatives:

Modify the recommended installation directory to comply with FHS.
- For example, either /opt/kiauh or /usr/local/kiauh can be reasonably assumed to be a fixed path regardless of distro and does not interfere with a user's home directory.
- This is probably the "most proper" solution, but it's undoubtedly a breaking change.
Short-term solution: check for the expected working directory and gracefully handle an incorrect directory.
- For example, Please extract KIAUH to ~/kiauh. or kiauh.sh must be located in ~/kiauh. Fix this? (Y/n)
Completely remove dependence on the working directory/path. (As carl1961 mentioned, this would break external scripts, so this is probably not optimal.)

Pardon the delayed response! IMO it's bad practice to ambiguously crash depending on the name of the working directory, especially if the tool is intended to be installed in the user's home directory. By [FHS](https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html), `/home` should only be used to store configuration data and a user's personal files. ([FHS v2.3](https://www.pathname.com/fhs/pub/fhs-2.3.pdf) formerly stated "Therefore, no program should rely on this location"; however, that was amended in 2015, and it can reasonably be assumed that /home is safe to store user-specific config files.) I see a couple of alternatives: - Modify the recommended installation directory to comply with FHS. - For example, either `/opt/kiauh` or `/usr/local/kiauh` can be reasonably assumed to be a fixed path regardless of distro and does not interfere with a user's home directory. - This is probably the "most proper" solution, but it's undoubtedly a breaking change. - Short-term solution: check for the expected working directory and gracefully handle an incorrect directory. - For example, `Please extract KIAUH to ~/kiauh.` or `kiauh.sh must be located in ~/kiauh. Fix this? (Y/n)` - Completely remove dependence on the working directory/path. (As carl1961 mentioned, this would break external scripts, so this is probably not optimal.)

dw-0 commented

2022-05-09 20:02:50 +02:00

(Migrated from github.com)

Modify the recommended installation directory to comply with FHS

This will not happen.

Short-term solution: check for the expected working directory and gracefully handle an incorrect directory

I think this is also not an ideal solution.

Completely remove dependence on the working directory/path.

This is probably what im going to try for. As i stated previously i don't see a real downside of it.

By FHS, /home should only be used to store configuration data and a user's personal files.

If you want your software you are using strictly apply to that standard, you are currently out of luck and shouldn't even consider installing anything from the klipper ecosystem since none of them respect the FHS 😄

> * Modify the recommended installation directory to comply with FHS This will not happen. > * Short-term solution: check for the expected working directory and gracefully handle an incorrect directory I think this is also not an ideal solution. > * Completely remove dependence on the working directory/path. This is probably what im going to try for. As i stated previously i don't see a real downside of it. > By [FHS](https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html), /home should only be used to store configuration data and a user's personal files. If you want your software you are using strictly apply to that standard, you are currently out of luck and shouldn't even consider installing anything from the klipper ecosystem since none of them respect the FHS 😄

dw-0 commented

2022-05-14 14:09:21 +02:00

(Migrated from github.com)

Commit 1d16235c24 should fix this request and will be live once the PR is merged.

Commit https://github.com/th33xitus/kiauh/pull/191/commits/1d16235c24362fc90edd8ea1b159bfd7561c4781 should fix this request and will be live once the PR is merged.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: h3n3/kiauh#194