I have a few lines of configurations that I need in my rsyslgog.
if $programname == 'project' then /var/log/file.log
When added to the end of the main rsyslog configuration file, /etc/rsyslog.conf, this configuration appears to be valid and functional.
However, when using the rsyslog.d directory I get a syntax error.
error during parsing file /etc/rsyslog.d/project.conf, on or before line 2: syntax error on token '==' [v8.32.0 try http://www.rsyslog.com/e/2207 ]
Is there anything in the main config that has to be parsed in advance, or is this a bug that should be reported to Fedora 27 developers?
As rsyslog author, I would assume that there is some include right in front of it that somehow renders your (valid) construct invalid. Red Hat unfortunately tends to stick to obsolete legacy format, and things like these can easily happen when this is used (after all, this was why we obsoleted it).
To hunt this down, I would check the config include that is included immediately in front of your own. If included via wildcards, the include order is sorted by filename.
Sorry, it was my bad. The configuration for my rsyslog config file was rewritten by my installer bash script, and that interpreted the $ sign as variable within the string. I should have double-checked the correctness of my config file.
Related
I'm having trouble installing Homebrew, and it looks like the problem (invalid byte sequence in UTF-8 (ArgumentError) error message) is due to a fault in my PATH. when I run echo $PATH, I get the following (be sure to scroll to the far right in the code block below to see the fault):
/usr/local/mysql/bin:/opt/subversion/bin/:/usr/local/bin:/usr/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:PATH=/usr/local/share/python:$PATH:PATH=/usr/local/share/npm/bin:$PATH:export PATH��:/usr/local/git/bin
I have no idea where those strange characters just before the /usr/local/git/bin path are coming from. I'm using bash (tried zshell, same problem). I can't find where this coming from. my .bash_profile file looks clean, too.
Examine your ~/.profile, ~/.bash_profile, and ~/.bashrc files. It is also possible that these values are being set in /etc/profile or other system-wide files, but the nature of the errors is such that I would assume they are the result of your own manual edits of your personal files. You're the best judge to decide what you may have changed and when.
Look for entries such as the following:
PATH='/usr/local/share/python:$PATH'
PATH='PATH=/usr/local/share/npm/bin:$PATH'
PATH='export PATH��:/usr/local/git/bin'
They should instead look like
PATH=/usr/local/share/python:$PATH
PATH=/usr/local/share/npm/bin:$PATH
PATH=$PATH:/usr/local/git/bin
# Not strictly necessary -- PATH is already exported
export PATH
See a pattern? These all add a value to PATH by setting it to prefix:$PATH or $PATH:suffix where the new prefix or suffix is the directory where you have installed a local package. Whether the new value should be a prefix or a suffix is probably of little consequence -- except if you are trying to override a system version (say, your /usr/local/git is installed because /usr/bin/git is too old -- then, it's important that your local version comes first in the PATH). There is also a minuscule speed difference the first time you run a command; the shell has to look in more places before finding it if it's at the end of the PATH.
The difference in quoting is significant -- PATH=$PATH:suffix expands to the old value of PATH with :suffix added on, whereas PATH='$PATH:suffix' replaces the old value of PATH with the literal string $PATH with :suffix added on. You're lucky none of this has ended up replacing your original PATH completely, which would render your shell by and large inoperable (at least until you discover that you have to use /bin/ls instead of just ls).
I'm using Sphinx on Windows.
Most of my documentation is for regular users, but there are some sub-pages with content for administrators only.
So I want to build two versions of my documentation: a complete version, and a second version with the "admin" pages excluded.
I used the exclude_patterns in the build configuration for that.
So far, it works. Every file in every subfolder whose name contains "admin" is ignored when I put this into the conf.py file:
exclude_patterns = ['**/*admin*']
The problem is that I'd like to run the build once to get both versions.
What I'm trying to do right now is running make.bat twice and supply different parameters on each run.
According to the documentation, I can achieve this by setting the BUILDDIR and SPHINXOPTS variables.
So now I have a build.bat that looks like this:
path=%path%;c:\python27\scripts
rem BUILD ADMIN DOCS
set SPHINXOPTS=
set BUILDDIR=c:\build\admin
call make clean
call make html
rem BUILD USER DOCS
set SPHINXOPTS=-D exclude_patterns=['**/*admin*']
set BUILDDIR=c:\build\user
call make clean
call make html
pause
The build in the two different directories works when I delete the line set BUILDDIR=build from the sphinx-generated make.bat file.
However, the exclude pattern does not work.
The batch file listed above outputs this for the second build (the one with the exclude pattern):
Making output directory...
Running Sphinx v1.1.3
loading translations [de]... done
loading pickled environment... not yet created
Exception occurred:
File "C:\Python27\lib\site-packages\sphinx-1.1.3-py2.7.egg\sphinx\environment.
py", line 495, in find_files
['**/' + d for d in config.exclude_dirnames] +
TypeError: coercing to Unicode: need string or buffer, list found
The full traceback has been saved in c:\users\myusername\appdata\local\temp\sphinx-err-kmihxk.log, if you want to report the issue to the developers.
Please also report this if it was a user error, so that a better error message can be provided next time.
Either send bugs to the mailing list at <http://groups.google.com/group/sphinx-dev/>,
or report them in the tracker at <http://bitbucket.org/birkenfeld/sphinx/issues/>.
What am I doing wrong?
Is the syntax for exclude_patterns in the sphinx-build command line different than in the conf.py file?
Or is there a better way to build two different versions in one step?
My first thought was that this was a quoting issue, quoting being notoriously difficult to get right on the Windows command line. However, I wasn't able to come up with any combination of quoting that changed the behavior at all. (The problem is easy to replicate)
Of course it could still just be some quoting issue I'm not smart enough to figure out, but I suspect this is a Sphinx bug of some kind, and hope you will report it to the Sphinx developers.
In the meantime, here's an alternate solution:
quoting from here:
There is a special object named tags available in the config file. It can be used to query and change the tags (see Including content based on tags). Use tags.has('tag') to query, tags.add('tag') and tags.remove('tag') to change
This allows you to essentially pass flags into the conf.py file from the command line, and since the conf.py file is just Python, you can use if statements to set the value of exclude_patterns conditionally based on the tags you pass in.
For example, you could pass Sphinx options like:
set SPHINXOPTS=-t foradmins
to pass the "foradmins" tag, and then check for it in your conf.py like so:
exclude_patterns = blah
if tags.has('foradmins'):
exclude_patterns = []
That should allow you to do what you want. Good Luck!
I'm trying to load hunchentoot via quicklisp in slime, and getting the following error:
READ error during COMPILE-FILE:
:ASCII stream decoding error on
#<SB-SYS:FD-STREAM
for "file [redacted]/dists/quicklisp/software/rfc2388-20120107-http/rfc2388.asd"
{100607B723}>:
the octet sequence #(196) cannot be decoded.
(in form starting at line: 29, column: 29,
file-position: 1615)
[Condition of type ASDF:LOAD-SYSTEM-DEFINITION-ERROR]
I get this when trying to run either:
(ql:quickload "hunchentoot")
Or simply:
(ql:quickload "rfc2388")
It seems that others are getting this too. I found one hint at a possible answer, saying:
The system file is encoded as UTF-8.
I'm not sure how to configure things so that SBCL on Windows starts with
UTF-8 as its default encoding for loading sources, but that's what you
need to do.
From there, I've tried (based on e.g. [this] adding the following to my emacs config:
(set-language-environment "UTF-8")
(setq slime-lisp-implementations
'((sbcl ("/opt/local/bin/sbcl") :coding-system utf-8-unix)))
(setq slime-net-coding-system 'utf-8-unix)
But... I still get the same error, even after completely re-starting emacs, to make sure I had a fresh Slime that was reading the above config.
So, what am I missing, and/or otherwise how can I get this to load?
Thanks in advance! (More thanks to come for a successful answer. ;)
Have you checked your locale settings? Emacs configuration only tells it what coding systems to set for communication between SLIME and SWANK.
You can check for locale settings with /usr/bin/locale, for example:
navi ~ » locale
LANG=pl_PL.UTF-8
LC_CTYPE=pl_PL.UTF-8
LC_NUMERIC=pl_PL.UTF-8
LC_TIME=pl_PL.UTF-8
LC_COLLATE="pl_PL.UTF-8"
LC_MONETARY=pl_PL.UTF-8
LC_MESSAGES=C
LC_PAPER=pl_PL.UTF-8
LC_NAME="pl_PL.UTF-8"
LC_ADDRESS="pl_PL.UTF-8"
LC_TELEPHONE="pl_PL.UTF-8"
LC_MEASUREMENT=pl_PL.UTF-8
LC_IDENTIFICATION=pl_PL.UTF-8
LC_ALL=
navi ~ »
Mine is setup for UTF-8 everywhere, as you can see, except for displaying 'C' messages.
Try this:
change into the .../quicklisp/dists/quicklisp/software/rfc2388* directory and load rfc2388.asd into a text editor.
Move down to the :author parameter of the defsystem form. Replace the author's name by the name given at the top of the file.
Store file using ASCII encoding.
Of course, when a new version of the library is published, the workaround gets lost. Or else store the modified project in local-projects.
With the original UTF-8 encoding still in effect, the DEBUGGER should present an INPUT-REPLACEMENT option to replace offending input characters by a replacement string. Choose that option, type "?" or "x" or any string you like at the prompt and then ENTER. The load then completes. Of course, that is not something you would like to do every time.
So the best idea is probably to send an email to the author and ask to provide an ascii version for quicklisp.
There should be a .cache directory in your HOME that contains all the fasl files. Sometimes removing those old fasl files seems to work for me when something goes wrong with compilation.
I'm using nano on a server via ssh; on that system, nano doesn't have syntax color enabled by default. So I copied these nanosyntax files (for alternative, see also #CraigBarnes' answer) on the server, and had set up ~/.nanorc as:
include "~/nanosyntax/syntax-nanorc/php.nanorc"
include "~/nanosyntax/syntax-nanorc/php2.nanorc"
include "~/nanosyntax/syntax-nanorc/sh.nanorc"
include "~/nanosyntax/syntax-nanorc/python.nanorc"
include "~/nanosyntax/syntax-nanorc/html.nanorc"
include "~/nanosyntax/syntax-nanorc/perl.nanorc"
include "~/nanosyntax/syntax-nanorc/ruby.nanorc"
include "~/nanosyntax/syntax-nanorc/js.nanorc"
Now, this is the thing; if I just call:
nano somefile.php
... no php syntax coloring is done. If I try to force:
nano --syntax=php somefile.php
... still no syntax coloring (shown as plain text). However, if I do:
nano ~/.nanorc
... then I do get syntax coloring (that corresponds to .nanorc type file) ?!
So obviously, syntax coloring as such works (i.e. shell and nano are capable of it) - except, it seems to be ignored for some languages, like in this case php ?!
So, does anyone know what is going on - and how could I get syntax coloring also for php files?
Thanks,
Cheers!
I just ran into the same problem, and I fiddled around a bit with the includes to find the error. Surprisingly, turns out that changing the inclusion order fixed the issue:
This works:
include "~/.nano/nanorc.nanorc"
include "~/.nano/sh.nanorc"
# more includes...
This fails to highlight sh files:
include "~/.nano/sh.nanorc"
include "~/.nano/nanorc.nanorc"
# more includes...
So I guess it's probably a bug (in nano 2.2.2; worked fine in nano 2.1.7)
Hm... well, it seems there has been an upgrade on that server I was using; originally, nano didn't have syntax coloring by default, which is why I used my own separate ~/.nanorc.
Now, however, on the upgraded server, nano seems to work with php syntax coloring by default - and me having my own separate ~/.nanorc seems to have conflicted; because, once I commented all the entries in the private ~/.nanorc (with an #), php syntax coloring was back!!
Whowouldathunkit ?! :)
Cheers!
EDIT: Just to add a couple of notes about nano:
As noted above, syntax coloring is forced with --syntax switch; to see which syntaxes are available:
grep 'include' /etc/nanorc | # find lines containing 'include' in nanorc
grep -v '^#' | # don't process lines that start with '#'
sed 's_.*/\(.*\)\.nanorc"_\1_' # extract plain filenames
Result of this command is something like:
nanorc
c
css
debian
gentoo
html
...
So to force "nanorc" syntax coloring, you use:
nano --syntax=nanorc /usr/share/nano/nanorc.nanorc
.. or forcing "bash" shell script syntax coloring (especially useful with bashrc) would be:
nano --syntax=sh ~/.bashrc
Those "nanosyntax" files on Google Code are nearly as bad as ones that come with nano by default.
nano's highlighting engine is more basic than something with nested contexts (e.g. GtkSourceView) but you don't have to settle for crappy highlighting:
https://github.com/craigbarnes/nanorc
The .XFDL file extension identifies XFDL Formatted Document files. These belong to the XML-based document and template formatting standard. This format is exactly like the XML file format however, contains a level of encryption for use in secure communications.
I know how to view XFDL files using a file viewer I found here. I can also modify and save these files by doing File:Save/Save As. I'd like, however, to modify these files on the fly. Any suggestions? Is this even possible?
Update #1: I have now successfully decoded and unziped a .xfdl into an XML file which I can then edit. Now, I am looking for a way to re-encode the modified XML file back into base64-gzip (using Ruby or the command line)
If the encoding is base64 then this is the solution I've stumbled upon on the web:
"Decoding XDFL files saved with 'encoding=base64'.
Files saved with:
application/vnd.xfdl;content-encoding="base64-gzip"
are simple base64-encoded gzip files. They can be easily restored to XML by first decoding and then unzipping them. This can be done as follows on Ubuntu:
sudo apt-get install uudeview
uudeview -i yourform.xfdl
gunzip -S "" < UNKNOWN.001 > yourform-unpacked.xfdl
The first command will install uudeview, a package that can decode base64, among others. You can skip this step once it is installed.
Assuming your form is saved as 'yourform.xfdl', the uudeview command will decode the contents as 'UNKNOWN.001', since the xfdl file doesn't contain a file name. The '-i' option makes uudeview uninteractive, remove that option for more control.
The last command gunzips the decoded file into a file named 'yourform-unpacked.xfdl'.
Another possible solution - here
Side Note: Block quoted < code > doesn't work for long strings of code
The only answer I can think of right now is - read the manual for uudeview.
As much as I would like to help you, I am not an expert in this area, so you'll have to wait for someone more knowledgable to come down here and help you.
Meanwhile I can give you links to some documents that might help you:
UUDeview Home Page
Using XDFLengine
Gettting started with the XDFL Engine
Sorry if this doesn't help you.
You don't have to get out of Ruby to do this, can use the Base64 module in Ruby to encode the document like this:
irb(main):005:0> require 'base64'
=> true
irb(main):007:0> Base64.encode64("Hello World")
=> "SGVsbG8gV29ybGQ=\n"
irb(main):008:0> Base64.decode64("SGVsbG8gV29ybGQ=\n")
=> "Hello World"
And you can call gzip/gunzip using Kernel#system:
system("gzip foo.something")
system("gunzip foo.something.gz")