1

kdevelop provides this AppImage binary:

wget -O KDevelop.AppImage https://download.kde.org/stable/kdevelop/5.1.1/bin/linux/KDevelop-5.1.1-x86_64.AppImage
chmod +x KDevelop.AppImage
./KDevelop.AppImage

It works well. So I want to make a soft link called kd to that binary in /usr/bin, eg:

/usr/bin/sudo ln -s KDevelop-5.1.1-x86_64.AppImage kd

Now if I run kd file1, I'd expect that it would open a file name file1 in the current folder, but it always tries to open a file name file1 in my home folder - which is not where it should be.

Is there some way to fix this issue?

artm
  • 17,291
  • 6
  • 38
  • 54
  • 1
    May be, the appl. behaves different if not called with its original binary name. Did you try to use `alias kd=KDevelop-5.1.1-x86_64.AppImage` instead of `ln -s`? – Scheff's Cat Jul 09 '17 at 06:51
  • Perhaps a function called kd can help. – Cyrus Jul 09 '17 at 07:46
  • @Scheff thanks, I tried `alias kdd='/usr/bin/KDevelop-5.1.1-x86_64.AppImage'` but same issue with alias `kdd` - it always open file in home folder. – artm Jul 09 '17 at 09:44
  • 1
    The function trick of @Cyrus could be combined with e.g. `"$PWD/$1"` to prefix the file name with the current directory. – Scheff's Cat Jul 09 '17 at 10:12
  • @Scheff I actually used that "`pwd`/file1" - it worked, just not quite sure whether this is an _expected_ behavior or some buggy stuff; I don't recall having to prefix `pwd` with any other application I used before ;) – artm Jul 09 '17 at 10:17

1 Answers1

1

Some possible causes:

  • The application always assumes that you want to open files in your home directory, effectively or literally prepending $HOME to the path. This would be a bug in any *nix program, and should be reported.
  • The application behaves differently when $(basename "$0") is not KDevelop.AppImage (what @Scheff said).
  • You are actually running a different kd.

Possible workarounds/investigations:

  • Pass the full path to the file on the command line. If it tries to open /home/you//full/path/you/provided it is obviously buggy, and you have a test case. If it does not, then there might be some gotcha to what your $PWD actually is. Try checking its value before running.
  • Symlink with the same name, using sudo ln -s KDevelop-5.1.1-x86_64.AppImage /usr/bin, and try running that. If it behaves the same, you've at least proven that the symlink is not the problem.
  • Run type -a kd and verify that your /usr/bin/kd comes up first. If not there might be an alias or shell built-in which takes precedence.

That said, what is the actual error message?

l0b0
  • 55,365
  • 30
  • 138
  • 223
  • thanks, I tried `alias kdd='/usr/bin/KDevelop-5.1.1-x86_64.AppImage'` but same issue with alias `kdd` - it always open file in home folder. There was actually no error message, it's just that kdevelop keeps assuming file in _home_ folder instead of _current_ folder where the command is issued – artm Jul 09 '17 at 09:47
  • I agree this might be a bug with kdevelop AppImage; could not see any problems with symlinks etc. see self answer – artm Jul 09 '17 at 10:11