When trying to generate a man page with asciidoc, like this:
a2x -v -f manpage foobar.1.txt
I get the error manpage document title is mandatory. How do I fix this?
The line of =s under the man page title at the top of the file has to be of the same length as the line above it. This will cause the error:
FOO-BAR-QUUX(1)
========
This will fix it:
FOO-BAR-QUUX(1)
===============
Related
I'm trying to write a man page in markdown so it displays correctly on Github, but can also be converted to a real man page.
To convert it, I use pandoc. It mostly works fine, except for the "options" part.
If I write normal markdown like this:
# OPTIONS
**-h**
: Display help
**-v**
: Verbose
**-o**, **\--other**
: Some other option with a much longer description
spanning several lines
it works fine to make a real man page with
pandoc mytest.1.md -s -t man -o mytest.1
But on Github, the md file is displayed with the descriptions starting with ": " and not indented. And in fact, I just realized it's the same here on SO:
OPTIONS
-h
: Display help
-v
: Verbose
-o, --other
: Some other option with a much longer description spanning several
lines
How can I write a man page in Markdown that displays correctly on Github, with indenting and can also be converted to a real man page?
With exiftool I could not edit some tags like the result after when I put this line
exiftool logo.jpg -"Photoshop Quality"=""
I get this message
Warning: Sorry, Photoshop is not writable
Nothing to do.
My question . why ? how can i fix this problem ? . also I tried this line
exiftool logo.jpg -all=""
all of tags are removed exception of some like . . . .
File Size
File Type
So at the first did not edit . But in the second code worked ?
"Photoshop Quality" is not the name of a tag, it is the description. Make sure you use the command in exiftool FAQ #2 to figure out the correct name to process. You can also look at the Photoshop Tag page to see more info on the Photoshop tags.
The second command will remove all embedded tags in the file, but some tags are actually properties of the file, not embedded information. FileSize, for example, is the actual size of the file as reported by the underlying OS. FileType is the type of the file. These items can't just be changed on a whim, nor can they be removed.
I want to put keywords and comments in my source file.
the keywords documentation for gettext says: if keywordspec is of the form ‘id:argnum...,"xcomment"’, xgettext, when extracting a message from the specified argument strings, adds an extracted comment xcomment to the message.
I couldn't find any samples to help me with this.
This is my X-Pedit-KeywordsList header,
"X-Poedit-KeywordsList: __;_ex;\n"
And this is a sample line in my php source code:
_ex("unlock_level", "Available at level #.")
I expect the output to be:
# "Available at level #."
msgid "unlock_level"
How should I edit my keywordslist header (and/or the source)?
An example for the keyword spec (bourne shell syntax!) is:
xgettext --keyword='_ex:1,"my comment"' so.php
Unfortunately, this is not what you want. It produces this po entry:
#. my comment
#: so.php:3
msgid "unlock_level"
msgstr ""
The above command-line translates to "extract the first argument all all calls to _ex() as the msgid, and always add the comment 'my comment' to the PO entry". You can only specify which arguments are the singular, the plural, or the message context.
The X-POEdit-KeywordsList seems to be a custom header used by POEdit. It doesn't help you either.
You can kind of achieve the desired result by changing your sources to this:
<?
# TRANSLATORS: Available at level #.
_ex("unlock_level");
?>
Now invoke xgettext like this:
xgettext --add-comments=TRANSLATORS: --keyword=_ex so.php
You get this PO entry:
#. TRANSLATORS: Available at level #.
#: so.php:3
msgid "unlock_level"
msgstr ""
The option --add-comments=TRANSLATORS: has the effect that it adds comments that immediately precede a keyword iff that comment starts exactly with the string "TRANSLATORS:". You can exchange "TRANSLATORS:" with a string of your choice. You can also omit the argument to --add-comments and extract all comments that immediately precede keywords.
Not quite what you originally wanted but as close as you can get.
Poedit supports translator comments. I ended up adding localization keys to my source file like this:
// TRANSLATORS: "Available at level #."
__("unlock_level")
And this is what I get in my po file by pressing the update button in Poedit:
#. TRANSLATORS: "Available at level #."
msgid "unlock_level"
I just came across this post because I was also looking for a way to do this, and just wanted to add that #Paiman Roointans' solution works because PoEdit uses the TRANSLATORS: tag as default tag for comment extraction via gettext.
This can actually be seen if you open PoEdit -> Preferences -> Extractors, then click on the little "+" button at the bottom left of the window, which will show you the command PoEdit fires by default for an extraction of your translation strings from the source file, which is sth like:
xgettext -L PHP --add-comments=TRANSLATORS: --force-po -o %o %C %K %F
where %o %C %K %F are the respective placeholders, for example %o for the output filename, %K for the keyword list (you specify in POEdits keyword mask), etc.
To change the default comment identifier in PoEdit, simply go to Translation -> Properties -> Click on "Advanced Extraction Preferences" under de "Translation Properties" tab of the window which then pops up. Normally the first field there should tell you the current string being used as comment identifying tag. Change that for example to mysamplecommentkey, and write a translation like this in your PHP code, for example:
/* mysamplecommentkey: This is a test */
gettext( "Translate Me" );
And your "Translate Me" will have the This is a test comment attached to it when extracting from the source code.
And, just another point: You should rather use a POT instead of a PO template file for your gettext localizations in PoEdit. Set all of your keyword extractors and / or comment identifier string, then extract from your source code into your .pot file, everytime when you update your translations.
Then, in all of your PO files, you simply hit update from POT-File in PoEdit, and it will correctly update all of your translations, including all of the comments for translators, which will all be drawn from the POT file directly too (so you better write these translator comments in a language that all of your translators most likely understand).
It took me some time to figure all of this out, and I would have saved tons of hours if I knew all of this from upon the beginning, so I wanted to share this here. If used correctly, PoEdit (already the free version of it) can save you a lot of time!
If I go to Filelist in the Typo3 backend and check the option to display thumbnails, I only see broken image links.
Yet I remember that the thumbnails displayed ok at some point.
A test of ImageMagick in the install tool of typo shows, that ImageMagick is working ok.
What to do?
It's not only RealURL's problem - although it's most common while users are manipulating this file manually to add custom rules. Anyway this problem also ocures with typo3conf/localconf.php.
How to confirm:
Right click on the broken image and choose Open image in new window it will open a file with address like: http://somedomain.tld/typo3/thumbs.php?&file=..%2Fuploads%2...etc use some browser to preview the source code ie. in Chrome prepend the address with view-source: like: view-source:http://somedomain.tld/typo3/thumbs.php?&file=...etc. There should not be any whitespaces before the code of image...
How to prevent?
As you wrote. Check your config files like realurl_conf.php or localconf.php and make sure that there are no spaces before <?php. In case of script ending.... just remove the ?> tag, so script will end automatically without white spaces (even if you'll add 100 empty lines after last line of code), unfortunately sometimes finding this one annoying space in configs takes hours, so....
How to fix permanently?
I'm surprised, that isn't fixed after all these years still, while it's quite easy with ob_end_clean(), edit file: t3lib/thumbs.php, at the beginning (ie. right after php tag) add line:
<?php
ob_start();
Next find main() method, add at its begining line for cleaning output buffer, which will remove all garbage included from other files:
function main() {
ob_end_clean(); //here
...
Voila!
After Plesk update on one of servers by client's sysadmin we get an empty file /tmp/.tmp.err which was autoprepended with auto_prepend_file in php configuration.
So, all TYPO3 PHP scripts were prepended with an empty string. All dynamic thumbnails and dynamically generated XMLs were broken. Some unique situation, but probably could help to somebody.
In our case an old version of the extension 'spamshield' cause the same error.
We had Typo3 4.7.15 and 'spamshield' 1.0.2.
Please check server error logs for entries like:
PHP Warning: require_once(PATH_tslibclass.tslib_pibase.php): failed to open stream: No such file or directory in /typo3conf/ext/wt_spamshield/Classes/Extensions/class.tx_wtspamshield_extensions_abstract.php on line 25, referer: http://domain.tld/typo3/sysext/cms/layout/db_layout.php?id=16
[Tue Sep 17 09:46:13 2013] [error] [client 92.203.10.178] PHP Fatal error: require_once(): Failed opening required 'PATH_tslibclass.tslib_pibase.php' (include_path='/typo3/contrib/pear/:.:/usr/local/php-5.3/lib/php') in /typo3conf/ext/wt_spamshield/Classes/Extensions/class.tx_wtspamshield_extensions_abstract.php on line 25, referer: http://domain.tld/typo3/sysext/cms/layout/db_layout.php?id=16
Updating 'spamshield' to 1.1.0 fixed it.
There is a good chance that you may have the extension
rearUrl
installed.
Please check the realUrl config.
Typically this is located in
typoroot/typo3conf/
and is named realurlconf.php, realurl_conf.php or realurl_autoconf.php
Make sure there is no comment or whitespace lines before the <?php tag, as well as none after the closing php tag at the end.
Clear typo caches, then it works again.
I want to write the manpage for my CLI-script with Asciidoc and convert it with
a2x --doctype manpage --format manpage MYMANPAGE.ASCIIDOC
I could not find any Asciidoc example out there which can successfully be converted to a manpage with this command.
Could you point me to an example or provide one?
Found an example - from the Asciidoc sources itself:
http://code.google.com/p/asciidoc/source/browse/doc/asciidoc.1.txt
(Still, more examples for Ascii-doc-formatted manpages very welcome!)
In addition to the link from #ifischer's answer, which provides a very useful example, I would like to direct readers to the following page from the asciidoc documentation: http://www.methods.co.nz/asciidoc/chunked/ch24.html.
In particular, it mentions that:
the title needs to be properly formatted (e.g: PROGRAM(1))
the doctype needs to be "manpage" (e.g: ":doctype: manpage")
the first section needs to be "Name". The contents of this section must also be properly formatted (e.g: "program - ...")
the second section needs to be "Synopsis". It appears the contents of this section can be anything, although standard manpage practice would be to list all of the program invocation options.
The document must of course be a properly formatted asciidoc document.
There are optional pieces of information which can be set for the manpage via ":directives:" in the document header.
When you run a2x, it will automatically name the outputted manpage based on the contents of the name section and title. I believe it's always named "name.x", where name is from the name section and x is the number from the title.