I strongly and totally politely and not a bit hostilely suggest that you read this whole page, particularly the FAQs, before running TTYtter.
First, make sure you are using at least TTYtter 2.1 and not any prior version. When Twitter API 1.1 takes full effect, no prior version will work.
Then, check your system's clock. If your clock is off more than a few minutes in any direction, Twitter may give you that message. It's NTP time, homeslice.
You can also see this message if your cURL's root certificates are out of date. If adding -k to your ~/.curlrc fixes the problem (by disabling certificate verification), you need to fix this. See this note (for MacPorts, but generally true for all OSes) and our documentation on using TTYtter with SSL.
Streaming API has specific requirements, including cURL, SSL and a valid user account. You must also opt in explicitly using -dostream or putting in dostream=1 in your ~/.ttytterrc. If you don't actually want the Streaming API, you don't have to use it; the message is informational and TTYtter will fall back on the slower REST API. See TTYtter and the Streaming API.
The background runs asynchronously, meaning that TTYtter will faithfully print tweets every update cycle, even if you are typing or using the console. This is by design. In streaming mode, this will happen immediately as a tweet is received.
For many users, simply pressing CTRL-R to repaint the current line will refresh what you're doing. If this is sufficient, you don't need to do anything else.
Otherwise, you can install a readline driver. This gives you a prompt that stays up to date as screen updates occur. We recommend our own Term::ReadLine:TTYtter (download from below) that even gives you a character counter.
If you just want to stop the background from updating until you ask for it, or can't use a readline driver and this really does drive you up the wall, then use the -synch option. Then, nothing happens until after your command is typed. However, if you leave that terminal idle, then no updates will occur in this mode, so you might want to consider one of the other options first.
See the section on TTYtter and UTF-8 support.
Use stty at your shell to set your correct backspace key (either DEL or BS), with something like stty erase ^? (for DEL) or stty erase ^H (for BS). The easiest way is to type stty erase, a SPACE, CTRL-V and press your backspace key. The right sequence will be inserted. Hit RETURN/ENTER, then start TTYtter. If you have to do this a lot, consider putting it in your login script(s).
For some users, picking one or the other is necessary. You can try, for example, using ASCII 0x08 for your backspace: stty erase SPACE CTRL-V CTRL-H RETURN/ENTER
Those messages are informational only, and reflect network conditions. If Twitter is having problems, or your network is down, you will see these. These are non-fatal messages.
Similarly, messages like *** JSON warning: ... are problems with the data received from Twitter, not TTYtter, normally that the JSON is incomplete or not properly parseable. TTYtter will automatically refetch until it gets something it can use.
The reason these messages are printed is so you can see immediately why tweets aren't being fetched or posted.
Twitter API 1.1 reduces the rate limit available for API applications compared to the original API, sometimes significantly. However, by default and assuming normal usage, TTYtter is designed to use no more than 50% of the declared rate limit for fetching tweets and DMs. Posting DMs and tweets do not count against your limit. If you're running over the rate limit, check the following:
Use -ansi, or put ansi=1 in your .ttytterrc. See Command-line options.
See the section on TTYtter and SSL.
TTYtter reports the driver it is using on startup. By default, it looks for Term::ReadLine::TTYtter; if it doesn't find it, it falls back on the basic but impoverished ::Stub driver. You can tell Term::ReadLine to use a different driver by setting the PERL_RL environment variable before starting TTYtter. For example, in tcsh, setenv PERL_RL Perl or setenv PERL_RL Gnu will select T::RL::Perl or T::RL::Gnu respectively. You can also install Term::ReadLine::TTYtter, of course.
If you have multiple Perls installed on your computer (such as, on Mac OS X, the system-provided Perl and the MacPorts Perl), make sure you are running TTYtter with the right Perl or it won't see T::RL::T (even though it's technically installed somewhere, it's not installed in that Perl's view).
Yes! TTYtter has direct support for lists.
ttytter has been tested against
Perl 5.8.6, 5.12.3 and
5.14.0 running on Mac OS X 10.4.11 (PowerPC) with cURL 7.16.3;
Perl 5.8.9 running on AIX 6.1 (POWER6) with cURL 7.21.4;
Perl 5.8.9 running on Mac OS X 10.5.8 (x86_64) with cURL 7.20.0;
Perl 5.10.1 running on NetBSD/x86_64 with cURL 7.20.0;
Perl 5.12.0 running on Ubuntu 10.04;
and Perl 5.10.0 on Knoppix and Perl 5.8.8 running on the OLPC XO-1
connecting both directly and through an HTTP proxy
(configured for Lynx/curl). It is guaranteed to make Larry Wall
nauseous just looking at it. There are also successful reports from users
Important support note for Perls < 5.8.6
The version 1.1 branch was the last version to include out-of-the-box
support for versions of Perl prior to 5.8.6. Starting with version 1.2,
there is no routine testing on 5.005 or 5.6
as I am not using
TTYtter on those machines routinely. However, none of the existing
compatibility code will be removed unless necessary, and patches for these
earlier versions of Perl
will still be accepted assuming they are reasonable (in my sole judgment)
and work without modification on later Perls. To run TTYtter
under 5.005 or 5.6, you must pass the -oldperl option, or put
oldperl=1 in your .ttytterrc. Bug reports for
these earlier versions without patches will be ignored as I have no
ability to test code on them. Please note Perl 5.004 and previous have
never been supported. Send your patches to me at
Changes in version 2.1.0:
Changes in version 2.0.1:
If your TTYtter abruptly quits when you type commands, your system does not support these signals correctly. Send me a report so that I can investigate a workaround.
Send comments and blank cheques to firstname.lastname@example.org.