[Aspell-user] aspell - Unknown mode: "nroff"

[Cook, Kevin J]

I am trying to get aspell to work on my Linux RedHat server. Here is what
I am doing and the return message.

-sh-4.1$ /usr/bin/aspell -a --lang=en_US < dead.letter
WARNING: Unable to enter Nroff mode: Unknown mode: "nroff".
Error: No word lists can be found for the language "en_US".

Any ideas?

[Kevin Atkinson]

Hi,

Post by Cook, Kevin J
-sh-4.1$ /usr/bin/aspell -a --lang=en_US < dead.letter
WARNING: Unable to enter Nroff mode: Unknown mode: "nroff".
Error: No word lists can be found for the language "en_US".

It looks like Aspell is not installed correctly. It is looking for the
nroff filter. More specifically it needs to be able to find the files
"nroff.amf" "nroff-filter.info" and "nroff-filter.so".

As a work around you could use:

/usr/bin/aspell --mode=none -a --lang=en_US < dead.letter

Kevin

[Kevin Atkinson]

That doesn't work either.
-sh-4.1$ /usr/bin/aspell --mode=none -a --lang=en_US < dead.letter
Error: Unknown mode: "none".

Sorry I thought that would work. It is now looking for the file
"none.amf". Did you install Aspell from source or from an rpm?

[Kevin Atkinson]

[Please keep your reply to the lists. I am CC the list in my replies.]

I do not know. My Sys Admin installed it. And I am positive he will
not even remember a thing about it.
Would it be a problem if he just re-installed it? Does he need to
un-install it first? Where is the download for him to install it?

It may be helpful to uninstall it first. Tell him Aspell is looking for
the file "none.amf" and can't find it. I can not assist you any more in
this matter.

Kevin

[Agustin Martin]

[Seems that the old hispalinux alias I was using for the subscription is not
working as expected. Resubscribed with other email in case old one cannot be
recovered.]

Post by Kevin Atkinson
[Please keep your reply to the lists. I am CC the list in my replies.]

I do not know. My Sys Admin installed it. And I am positive he will not
even remember a thing about it.
Would it be a problem if he just re-installed it? Does he need to
un-install it first? Where is the download for him to install it?

It may be helpful to uninstall it first. Tell him Aspell is looking for the
file "none.amf" and can't find it. I can not assist you any more in this
matter.

Hi, Kevin,

This has been reported in Debian as happening when 'data-dir' and 'lib-dir'
do not match

https://bugs.debian.org/612051

The temporary workaround at that time was to make them match again.

Looking at

https://bugs.debian.org/667592 [libaspell15: please add multiarch support]

I was playing with some things there, and found this problem when 'data-dir'
and 'lib-dir' are set to diferent values.

I have straced the failing aspell call and seems I know what is happening.
The relevant parts are, when checking a tex file,

...
open("/usr/lib/aspell/tex.amf", O_RDONLY) = 5
...
access("/usr/lib/aspell/tex-filter.info", F_OK) = -1 ENOENT (No such file or directory)
write(2, "Error: The filter \"tex\" does not"..., 40Error: The filter "tex" does not exist.

With 'lib-dir=/usr/lib/aspell' and 'data-dir=/usr/share/aspell', aspell
installs ".amf" files under /usr/lib/aspell, but installs "*-filter.info"
under /usr/share/aspell, making aspell fail when looks for tex-filter.info
under /usr/lib/aspell.

I have been playing with patch below which, once propagated to the autotools
buildchain, tries to install all filter related things under 'lib-dir'. This
seems to make aspell work again in such cases.

Regards,

[Kevin Atkinson]

Hi,

I am not fully following everything mentioned, but here one helpful
tidbit of information. :)

The Aspell config option "filter-path" controls where Aspell looks for
filters. This defaults to the same location Aspell looks for
dictionaries, which defaults to "/usr/lib/aspell". For help in changing
this value see http://aspell.net/man-html/Customizing-Aspell.html.
Aspell can also be compiled with a different default for "filter-path",
but will likely involve having to patch common/config.cpp.

Thanks,
Kevin

Post by Agustin Martin
[Seems that the old hispalinux alias I was using for the subscription is not
working as expected. Resubscribed with other email in case old one cannot be
recovered.]

Post by Kevin Atkinson
[Please keep your reply to the lists. I am CC the list in my replies.]

I do not know. My Sys Admin installed it. And I am positive he will not
even remember a thing about it.
Would it be a problem if he just re-installed it? Does he need to
un-install it first? Where is the download for him to install it?

It may be helpful to uninstall it first. Tell him Aspell is looking for the
file "none.amf" and can't find it. I can not assist you any more in this
matter.

Hi, Kevin,
This has been reported in Debian as happening when 'data-dir' and 'lib-dir'
do not match
https://bugs.debian.org/612051
The temporary workaround at that time was to make them match again.
Looking at
https://bugs.debian.org/667592 [libaspell15: please add multiarch support]
I was playing with some things there, and found this problem when 'data-dir'
and 'lib-dir' are set to diferent values.
I have straced the failing aspell call and seems I know what is happening.
The relevant parts are, when checking a tex file,
...
open("/usr/lib/aspell/tex.amf", O_RDONLY) = 5
...
access("/usr/lib/aspell/tex-filter.info", F_OK) = -1 ENOENT (No such file or directory)
write(2, "Error: The filter \"tex\" does not"..., 40Error: The filter "tex" does not exist.
With 'lib-dir=/usr/lib/aspell' and 'data-dir=/usr/share/aspell', aspell
installs ".amf" files under /usr/lib/aspell, but installs "*-filter.info"
under /usr/share/aspell, making aspell fail when looks for tex-filter.info
under /usr/lib/aspell.
I have been playing with patch below which, once propagated to the autotools
buildchain, tries to install all filter related things under 'lib-dir'. This
seems to make aspell work again in such cases.
Regards,
_______________________________________________
Aspell-user mailing list
https://lists.gnu.org/mailman/listinfo/aspell-user

[Agustin Martin]

Hi,
I am not fully following everything mentioned, but here one helpful tidbit
of information. :)
The Aspell config option "filter-path" controls where Aspell looks for
filters. This defaults to the same location Aspell looks for dictionaries,
which defaults to "/usr/lib/aspell". For help in changing this value see
http://aspell.net/man-html/Customizing-Aspell.html.
Aspell can also be compiled with a different default for "filter-path", but
will likely involve having to patch common/config.cpp.

Hi, Kevin, thanks for the info

The problem is that part of the filter related stuff (in particular
tex-filter.info) gets installed under "pkgdatadir" instead of under
"pkglibdir", and aspell seems to look for all filter related stuff under
"filter-path" (pkglibdir). There is no problem if both match, but error
happens if they don't. My proposed change just tries to have all filter
related stuff installed under "pkglibdir" (and thus found by "filter-path").

Post by Agustin Martin
Looking at
https://bugs.debian.org/667592 [libaspell15: please add multiarch support]
I was playing with some things there, and found this problem when 'data-dir'
and 'lib-dir' are set to diferent values.

While we are at this (Possible multiarch implementation in Debian aspell
packages), just wanted to comment that I have been playing with the Debian
aspell package, here goes some info.

One thing I was playing with is the --enable-32-bit-hash-fun option as
proposed in that Debian bug report, making i386 and amd64 architectures
use the same binary format for compiled dictionaries.

I am also playing with a new option to allow explicit selection of a
different path for dictionaries, not coupled to pkglibdir unless the option
is not set. The idea is to try to make i386 (i386-linux-gnu) and amd64
(x86_64-linux-gnu) libs coinstalable, with a working Debian multiarch
structure like

/usr/lib/aspell: dicts, valid for both architectures.
/usr/lib/{i386,x86_64}-linux-gnu: General purpose libs (libaspell...)
/usr/lib/aspell/{i386,x86_64}-linux-gnu: Aspell filters and friends
/usr/share/aspell: Data files

Preliminary stuff seems to work well, but I still need to think more about
all this.

Regards,

[Kevin Atkinson]

Hi,

Post by Agustin Martin

Hi,
I am not fully following everything mentioned, but here one helpful tidbit
of information. :)
The Aspell config option "filter-path" controls where Aspell looks for
filters. This defaults to the same location Aspell looks for dictionaries,
which defaults to "/usr/lib/aspell". For help in changing this value see
http://aspell.net/man-html/Customizing-Aspell.html.
Aspell can also be compiled with a different default for "filter-path", but
will likely involve having to patch common/config.cpp.

Hi, Kevin, thanks for the info
The problem is that part of the filter related stuff (in particular
tex-filter.info) gets installed under "pkgdatadir" instead of under
"pkglibdir", and aspell seems to look for all filter related stuff under
"filter-path" (pkglibdir). There is no problem if both match, but error
happens if they don't. My proposed change just tries to have all filter
related stuff installed under "pkglibdir" (and thus found by "filter-path").

That is one way, but Aspell can likely also be configured to find things
where they are now.

Post by Agustin Martin

Post by Agustin Martin
Looking at
https://bugs.debian.org/667592 [libaspell15: please add multiarch support]
I was playing with some things there, and found this problem when 'data-dir'
and 'lib-dir' are set to diferent values.

While we are at this (Possible multiarch implementation in Debian aspell
packages), just wanted to comment that I have been playing with the Debian
aspell package, here goes some info.
One thing I was playing with is the --enable-32-bit-hash-fun option as
proposed in that Debian bug report, making i386 and amd64 architectures
use the same binary format for compiled dictionaries.

I don't see any major drawback to this. Maybe a slight speed penalty on
amd64 architectures.

Post by Agustin Martin
I am also playing with a new option to allow explicit selection of a
different path for dictionaries, not coupled to pkglibdir unless the option
is not set. The idea is to try to make i386 (i386-linux-gnu) and amd64
(x86_64-linux-gnu) libs coinstalable, with a working Debian multiarch
structure like
/usr/lib/aspell: dicts, valid for both architectures.
/usr/lib/{i386,x86_64}-linux-gnu: General purpose libs (libaspell...)
/usr/lib/aspell/{i386,x86_64}-linux-gnu: Aspell filters and friends
/usr/share/aspell: Data files
Preliminary stuff seems to work well, but I still need to think more about
all this.

Like I said below, Aspell can likely be configured to make that work.
If you do get anywhere please post a patch so I can review it.

It might be a good idea to take this thread to aspell-devel.

Kevin

[Cook, Kevin J]

This was working until we went to ssl (https). Would that have made a
difference?