Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Cabal mangles exceptions #823

Open
bos opened this Issue May 24, 2012 · 7 comments

Comments

Projects
None yet
6 participants
Contributor

bos commented May 24, 2012

(Imported from Trac #833, reported by @igloo on 2011-04-21)

Cabal mangles exceptions, e.g.:

$ "utils/ghc-cabal/dist/build/tmp/ghc-cabal" install "/home/ian/ghc/git/ghc/bindisttest/install dir/lib/ghc-7.1.20110421/ghc" "/home/ian/ghc/git/ghc/bindisttest/install dir/lib/ghc-7.1.20110421/ghc-pkg" ":" "/home/ian/ghc/git/ghc/bindisttest/install dir/lib/ghc-7.1.20110421" libraries/ghc-prim dist-install '' '/home/ian/ghc/git/ghc/bindisttest/install dir' '/home/ian/ghc/git/ghc/bindisttest/install dir/lib/ghc-7.1.20110421' '/home/ian/ghc/git/ghc/bindisttest/install dir/share/doc/ghc/html/libraries'
Installing library in /home/ian/ghc/git/ghc/bindisttest/install
dir/lib/ghc-7.1.20110421/ghc-prim-0.2.0.0
ghc-cabal: /home/ian/ghc/git/ghc/bindisttest/install
dir/lib/ghc-7.1.20110421/settings: openFile: does not exist (No such file or
directory)
where a space in the filename has been replaced with a '\n'. This can be very confusing!

It looks like Distribution.Simple.Utils.topHandler / wrapText is the culprit.

Contributor

manzyuk commented May 3, 2013

I'm at OdHac at the moment and am trying to do some work on Cabal, so I've looked at this issue for warmup.

The problem is indeed in the function Distribution.Simple.Utils.wrapText, which is used to wrap messages at 79 characters. No attempt is made to detect whether a space at which a line is wrapped is part of a file name. One can reproduce the problem more easily as follows:

$ cabal install http://hackage.haskell.org/packages/archive/groups/0.2.0.1/groups-0.2.0.1.tar.gz --prefix "/home/manzyuk/foo/bar/baz quux"
Downloading
http://hackage.haskell.org/packages/archive/groups/0.2.0.1/groups-0.2.0.1.tar.gz
Resolving dependencies...
In order, the following will be installed:
groups-0.2.0.1 (reinstall)
Warning: Note that reinstalls are always dangerous. Continuing anyway...
Configuring groups-0.2.0.1...
Building groups-0.2.0.1...
Preprocessing library groups-0.2.0.1...
[1 of 1] Compiling Data.Group ( src/Data/Group.hs, dist/build/Data/Group.o )
In-place registering groups-0.2.0.1...
Installing library in /home/manzyuk/foo/bar/baz
quux/lib/groups-0.2.0.1/ghc-7.4.1
Registering groups-0.2.0.1...
Installed groups-0.2.0.1

Note that the line starting with "Installing library in" is wrapped at the space that is part of a directory name.

I suppose, a proper way to fix it would be to use an algebraic data type rather than String to represent messages, something like Text.PrettyPrint.Doc, so that file names can be treated as unbreakable entities that shouldn't be wrapped. This, however, seems to require quite some re-engineering of error handling in Cabal. Should I go ahead and do it?

Member

23Skidoo commented May 3, 2013

@manzyuk

This, however, seems to require quite some re-engineering of error handling in Cabal. Should I go ahead and do it?

I think it's a minor issue and your efforts are better spent elsewhere.

Member

23Skidoo commented May 9, 2013

An alternative solution would be to enclose all paths inside single quotes and then make wrapText treat all text inside single quotes as a single word. Example:

In-place registering groups-0.2.0.1...
Installing library in 
'/home/manzyuk/foo/bar/baz quux/lib/groups-0.2.0.1/ghc-7.4.1'
Registering groups-0.2.0.1...

@ttuegel ttuegel added this to the _|_ milestone Apr 23, 2015

Collaborator

BardurArantsson commented Nov 7, 2015

... or perhaps simpler: Just remove the wrapping altogether?

I really don't understand why cabal making a judgement call here on 79 being the "correct" terminal width, instead of the user's actual terminal width -- in which case wrapping happens automatically anyway.

Member

23Skidoo commented Apr 10, 2016

I really don't understand why cabal making a judgement call here on 79 being the "correct" terminal width, instead of the user's actual terminal width

Long messages are easier to read that way on large terminals (e.g. widescreen-sized).

Contributor

ezyang commented Apr 10, 2016

Honestly, the correct way to do this is to throw pretty-printing documents rather than strings. Then the pretty-printer has enough information to correctly wrap.

Member

23Skidoo commented Apr 10, 2016

Yep, that's the same solution that @manzyuk proposed above.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment