AMQP-PUBLISH(1) RabbitMQ C Client AMQP-PUBLISH(1)NAME
amqp-publish - Publish a message on an AMQP server
SYNOPSIS
amqp-publish [OPTION...]
DESCRIPTION
Publishes a message to an exchange on an AMQP server. Options allow the various properties of the message and parameters of the AMQP
basic.publish method to be specified.
By default, the message body is read from standard input. Alternatively, the -b option allows the message body to be provided as part of
the command.
OPTIONS -e, --exchange=exchange name
The name of the exchange to publish to. If omitted, the default exchange (also known as the nameless exchange) is used.
-r, --routing-key=routing key
The routing key to publish with. If omitted, an empty routing key is assumed. A routing key must be specified when publishing to the
default exchange; in that case, accoding to the AMQP specification, the routing key corresponds to a queue name.
-p, --persistent
Use the persistent delivery mode. Without this option, non-persistent delivery is used.
-C, --content-type=MIME type
Specifies the content-type property for the message. If omitted, the content-type property is not set on the message.
-E, --content-encoding=content coding
Specifies the content-encoding property for the message. If omitted, the content-encoding property is not set on the message.
-b, --body=message body
Specifies the message body. If omitted, the message body is read from standard input.
EXAMPLES
Send a short message, consisting of the word "Hello" to the queue "myqueue" via the default exchange:
$ amqp-publish -r myqueue -b Hello
Send some XML data from a file to the exchange "events", with persistent delivery mode, setting the content-type property on the message to
make the data format explicit:
$ amqp-publish -e events -p -C text/xml <event.xml
SEE ALSO librabbitmq-tools(7) describes connection-related options common to all the RabbitMQ C Client tools.
AUTHOR
The RabbitMQ Team <info@rabbitmq.com>
RabbitMQ C Client 2011-01-01 AMQP-PUBLISH(1)
Check Out this Related Man Page
MHLIST(1) [nmh-1.5] MHLIST(1)NAME
mhlist - list information about MIME messages
SYNOPSIS
mhlist [+folder] [msgs] [-file file] [-part number] ... [-type content] ... [-headers | -noheaders] [-realsize | -norealsize] [-rcache
policy] [-wcache policy] [-check | -nocheck] [-verbose | -noverbose] [-version] [-help]
DESCRIPTION
The mhlist command allows you to list information (essentially a table of contents) about the various parts of a collection of MIME (multi-
media) messages.
mhlist manipulates MIME (multi-media messages) as specified in RFC-2045 thru RFC-2049 (See mhbuild(1)).
The -headers switch indicates that a one-line banner should be displayed above the listing.
The -realsize switch tells mhlist to evaluate the "native" (decoded) format of each content prior to listing. This provides an accurate
count at the expense of a small delay.
If the -verbose switch is present, then the listing will show any "extra" information that is present in the message, such as comments in
the "Content-Type" header.
The option -file file directs mhlist to use the specified file as the source message, rather than a message from a folder. If you specify
this file as "-", then mhlist will accept the source message on the standard input. Note that the file, or input from standard input
should be a validly formatted message, just like any other nmh message. It should NOT be in mail drop format (to convert a file in mail
drop format to a folder of nmh messages, see inc(1)).
By default, mhlist will list information about the entire message (all of its parts). By using the -part and -type switches, you may limit
the scope of this command to particular subparts (of a multipart content) and/or particular content types.
A part specification consists of a series of numbers separated by dots. For example, in a multipart content containing three parts, these
would be named as 1, 2, and 3, respectively. If part 2 was also a multipart content containing two parts, these would be named as 2.1 and
2.2, respectively. Note that the -part switch is effective for only messages containing a multipart content. If a message has some other
kind of content, or if the part is itself another multipart content, the -part switch will not prevent the content from being acted upon.
A content specification consists of a content type and a subtype. The initial list of "standard" content types and subtypes can be found
in RFC-2046.
A list of commonly used contents is briefly reproduced here:
Type Subtypes
------------
text plain, enriched
multipart mixed, alternative, digest, parallel
message rfc822, partial, external-body
application octet-stream, postscript
image jpeg, gif, png
audio basic
video mpeg
A legal MIME message must contain a subtype specification.
To specify a content, regardless of its subtype, just use the name of the content, e.g., "audio". To specify a specific subtype, separate
the two with a slash, e.g., "audio/basic". Note that regardless of the values given to the -type switch, a multipart content (of any sub-
type listed above) is always acted upon. Further note that if the -type switch is used, and it is desirable to act on a message/external-
body content, then the -type switch must be used twice: once for message/external-body and once for the content externally referenced.
Checking the Contents
The -check switch tells mhlist to check each content for an integrity checksum. If a content has such a checksum (specified as a Content-
MD5 header field), then mhlist will attempt to verify the integrity of the content.
FILES
$HOME/.mh_profile The user profile
PROFILE COMPONENTS
Path: To determine the user's nmh directory
Current-Folder: To find the default current folder
SEE ALSO mhbuild(1), mhshow(1), mhstore(1), sendfiles(1)DEFAULTS
`+folder' defaults to the current folder
`msgs' defaults to cur
`-nocheck'
`-headers'
`-realsize'
`-rcache ask'
`-wcache ask'
`-noverbose'
CONTEXT
If a folder is given, it will become the current folder. The last message selected will become the current message.
MH.6.8 11 June 2012 MHLIST(1)