8

The default kile version (Kile 2.9.91) shipped with kubuntu 18.04 does not behave as expected. In older versions this

$ kile myfile.tex

would open myfile.tex for editing. However, in the current version this tries and fails to open http://myfile.tex. The error message I get is "http://myfile.tex Host not found", which is not too surprising. I tried to wrap the filename in quotes, use kile ./myfile.tex and kile file://myfile.tex. The first did not change anything, the second and third resulted in a segfault.

What is the right way to open files using the command line in Kile 2.9.91?

What works, what doesn't?

$ kile myfile.tex                         -> Error: http://myfile.tex
$ kile "myfile.tex"                       -> Error: http://myfile.tex
$ kile myfile.txt                         -> Error: http://myfile.txt
$ kile myfile                             -> Error: http://myfile
$ kile Documents/myfile.tex               -> Error: http://documents/myfile.tex

$ kile ~/Documents/myfile.tex             -> Works!
$ kile /home/user/Documents/myfile.tex    -> Works!
$ kile $(realpath myfile.tex)             -> Works!

$ kile ./myfile.tex                       -> segfault
$ kile file://myfile.tex                  -> segfault
m00am
  • 606
  • 8
  • 27
  • 1
    I don't use Kile but in Kubuntu 18.04, the version should be 2.9.91. Where did you get Kile 3 from? – DK Bose Aug 28 '18 at 13:21
  • Oh, valid point, I only get a Kile 3 beta 1 banner / splash screen, the version is the one you say. I updated the question. Thanks for pointing that out. – m00am Aug 28 '18 at 13:28
  • 1
    I can reproduce your issue if I call kile myfile.tex on clean Ubuntu 18.04 LTS. But if I have myfile.tex in ~/Documents and open it with kile ~/Documents/myfile.tex it opens normally. On Ubuntu 16.04 LTS it does not need full file path. – N0rbert Aug 28 '18 at 18:08
  • 1
    Does this also happen with different file extensions (e.g. .txt) or no file extension at all (e.g. kile myfile)? – danzel Aug 28 '18 at 18:26
  • 1
    Thanks for the input. I added a table with all combinations that came to mind (and a dirty hacky workaround). – m00am Aug 29 '18 at 08:51
  • 2
    I have exactly the same issue. I am quite disgusted that the developers let such a blunder occur. – shuhalo Oct 23 '18 at 19:26
  • 1
    Added info and link to https://bugs.launchpad.net/ubuntu/+source/kile/+bug/1800355 – MoreIT Jul 07 '19 at 10:26

2 Answers2

2

Dirty workaround time: write a function into your .bashrc/ .zshrc (others might work these two are the only ones I tested) that calls realpath to get the absolute path of the input file:

function kile-open {
    kile $(realpath $1)
}

To regain the intended behavior (for one file at a time, not working with any other parameters, this can easily be improved with some bash knowledge). This is by no means a solution, just a way to mimic the intended behavior for now.

m00am
  • 606
  • 8
  • 27
1

Inspired by @m00am solution, in bash you can add the following to the .bashrc:

kile() { command kile $(realpath "$@") }

The command kile myfile.tex will then work. Personnally, I even redirect the output to /dev/null and release the command:

kile() { command kile $(realpath "$@") > /dev/null 2>&1 & }
xiawi
  • 121