Full path for _APTMGR in apt-fast.conf triggers script errors

[DogSledder]

The apt-fast.conf file states that _APTMGR can be set to a full path "e.g. /usr/bin/aptitude"; however, the apt-fast script contains code that compares _APTMGR to the strings "apt", "apt-get" and "aptitude". So, if _APTMGR is set to a full path, the comparisons in the script fail to work as might be expected.

I think that the comparisons should be done on only the file name part of the path.

Here's a little background:

I live in a rural area with very poor Internet service. Downloading large packages via apt-get can be challenging. I use apt-fast for the robustness of it's downloading, rather than for it's speed.

I was trying to redirect apt-get to apt-fast, so any invocation of apt-get would go to apt-fast instead. This was so that scripts that used apt-get would use apt-fast without any modification of the scripts themselves. For example, at time of writing, the mintupgrade script and the openHABian installation scripts use apt-get.

In my system, apt-get and apt-fast are located in the "/usr/bin" directory. To redirect apt-get to apt-fast, I created a link to "/usr/bin/apt-fast" named "apt-get". I placed the link in the "/usr/local/bin" directory. That directory is scanned before "/usr/bin" when resolving commands.

Of course, apt-fast invokes apt-get and that would have caused it to invoke itself. To overcome this problem, I specified the full path to the real apt-get via _APTMGR in "/etc/apt-fast.conf". That is to say, I set _APTMGR to "/usr/bin/apt-get".

This would have worked, except for the fact the the apt-fast script checks _APTMGR before getting package URIs. If _APTMGR is not the string "apt" or "apt-get", the script uses the command string "apt-get" to get package URIs. This is what happened in this case. _APTMGR contained "/usr/bin/apt-get", so the script used the command string "apt-get". This caused apt-fast to call itself, which failed with an error. I had expected it to use the command string "/usr/bin/apt-get".

Here is the code in question (around line 322):

  # Add header to overwrite file.
  echo "# apt-fast mirror list: $(date)" > "$DLLIST"
  #NOTE: aptitude doesn't have this functionality, so we use apt-get to get
  #      package URIs.
  case "$_APTMGR" in
    apt|apt-get) uri_mgr=$_APTMGR;;
    *) uri_mgr=apt-get;;
  esac
  uris_full="$("$uri_mgr" "${APT_SCRIPT_WARNING[@]}" -y --print-uris "$@")"

I changed the case statement to use the basename command as follows:

  case "$(basename "$_APTMGR")" in
    apt|apt-get) uri_mgr="$_APTMGR";;
    *) uri_mgr=apt-get;;
  esac

This worked for my use cases, but I noticed the script contains other instances where _APTMGR is used in similar comparison statements. I think these should be modified to use the basename command or corrected in some other way. Perhaps adding another setting in "/etc/apt-fast.conf" would be better.

[gothicVI]

Why not call apt-fast in the first place instead of doing the redirect stuff?

[DogSledder]

As I explained above, it's so that I could use installation scripts without having to modify them to use apt-fast.

[gothicVI]

Sorry, I must have missed that. What about using apt and apt-get. One for the linking and one for _APTMGR?

[DogSledder]

Using apt in _APTMGR might work, but it isn't advised for mint which uses it's own version of apt. Also, that doesn't address the general problem of using full pathnames in _APTMGR.

[guekho64]

Alright, I've confirmed that apt-fast.conf actually says that $_APTMGR is allowed to be a full path to a binary, so I'd say it's definitely a bug.

From my point of view, there are two possible solutions:

• We could simply remove this line, as apt-fast doesn't honor such behavior in practice.
• Or we could go ahead and try to fix every line of code where $_APTMGR is compared against another string.

IMO, I'd go for option #2, as I believe it's better to get this fixed now that has been reported.

[Lasall]

Thanks a lot for reporting this issue. If the issue still occurs, please feel free to reopen. Also please take a look at related PR #192