I'm using powerline, bash, and iterm2 on mac. I also installed gitstatus, but that didn't work when I installed it two days ago, and powerline worked just fine yesterday without gistatus functioning. Today, when I booted up the terminal, this error showed instead of the prompt.
Any advice? Where can I find the full log of the errors/interpret this message? Alternatively, how can I pinpoint which file has an error on line 55?
There error was in a color config file for the github integration. I was missing a comma at between lines. I believe it was in this file .config/powerline/colorschemes/default.json or another json related to it; see here.
Ultimately, I recommend moving to powerlevel10k. You can configure it to look exactly like powerline, but it a) updates cleanly (compared to powerline where if you update your python it breaks horribly) and b) comes with a really good customization setup and c) lets you use zsh + oh-my-zsh which gives so much additional functionality
Related
I have cygwin under Windows 8 and I've installed and run raku which I understand to be just Perl6.
I wanted to print some strings and numbers but say doesn't do the job (please see the black snippet below) it just do nothing unlike it is described here:
hynek0#hynek /cygdrive/c/Users/hynek0/Desktop/FU
$ raku --version
This is Rakudo version 2020.05.1 built on MoarVM version 2020.05
implementing Raku 6.d.
EDIT 2
EDIT 3
This is probably the same bug as reported with https://github.com/rakudo/rakudo/issues/4378 . It looks like Raku thinks there's nobody behind the keyboard ($*IN.t returning False) and thus switches to slurping the program to execute from STDIN.
At this point, I can only see a workaround: execute you example code with raku -e.
I am attempting to send a file from IFS to an outq on our AS/400 system. Whenever I do, I get exactly what I send, as well as a line of "#" symbols of varying lengths appended to the end.
Here's the command I'm using:
qsh cmd('cat -c /path/test.txt | Rfile -wbQ -c "ovrprtf file(qprint)
outq(*LIBL/ABCD) devtype(*USERASCII) rplunprt(*no) splfname(test) hold(*no)"
qprint')
The contents of test.txt is just Hello World!
The output I get when I send the command is
Hello World!####################################################################
I have not found any posts online about a similar problem, and have tried changing values and looking for additional switches to get it to work. Nothing I'm doing seems to fix the issue.
Is there a command or switch that I am missing, or is something I have in there already causing this?
EDIT:
I found this documentation which is the first time I've seen this issue mentioned, but it's not very helpful:
“Messages for a Take Action command might consist of a long string of "at" symbols (#) in a pop-up message. (The Reflex automation Take Action command, which is configured in situations, does not have this problem.) A resolution for this problem is under construction. This problem might be resolved by the time of the product release. If you see this problem, contact IBM Software Support.”
The only differences are: 1) this is not a pop-up message, it's printed. 2) I don't believe we use Tivoli Monitoring, although I could be wrong.
Assuming we do use Tivoli Monitoring, what would the solution be? There's no additional documentation past that, and I am not a system administrator, so I can't really make the call to IBM Software Support myself. And assuming we DON'T use it, what else could cause this issue?
I get different results, yet similar. I created a test.txt with Windows Explorer, put in Hello, world!, saved it and tried the script. I got gibberish for the 'Hello, world!' and then the line of # symbols.
My system is 7.3 TR5, CCSID 37 (US English) and my IFS file is CCSID 1252 (Windows English). Results did not change if I used a stream file of CCSID 819 (US ASCII).
I didn't have any luck modifying Rfile switches.
I found that removing devtype(*userascii) produced printed output in plain English without the # symbols. Do you really need *USERASCII? I would think that would be more for a pre-formatted 'print-ready' file like Postscript or the like.
EDIT: some more things to try
I don't understand why *USERASCII is adding those # symbols; it looks like a translation issue.
I tried this and still got the extra ###... You might have to play with the TOCCSID() parameter. Although a failure, it did give me an idea: what if those # symbols are EBCDIC spaces being sent as-is to the *USERASCII print stream? All we'd need is a way to send only the number of bytes in the stream file, without any padding.
CRTPF FILE(QTEMP/PRTSTMF) RCDLEN(132)
CPY OBJ('/path/test.txt') TOOBJ('/qsys.lib/qtemp.lib/prtstmf.file/prtstmf.mbr') replace(*yes)
ovrprtf file(qprint) outq(*LIBL/prt3812) devtype(*USERASCII) rplunprt(*no) splfname(test) hold(*no)
cpyf prtstmf qprint
The data in QTEMP/PRTSTMF is in ASCII; DSPPFM shows that much. It also shows a bunch of spaces: after all, it is a fixed length file. My next step was to write an RPG program to read the stream file and print it, but Scott Klement already did that: http://www.scottklement.com/PrtStmf.zip
This works on my system:
ovrprtf file(qsysprt) outq(*LIBL/abcd) devtype(*USERASCII) rplunprt(*no) splfname(test) hold(*no)
prtstmf stmf('/path/test.txt') outq(abcd)
Totally lacking intuition here.
First i thought i only happens when copying and pasting code from editor. Unfortunately it's more common. Only thing I am doing is trying to insert more code somewhere in the middle of current input or modifying it.
Expected behavior:
Modify input without side effects.
What actually happens:
VERY OFTEN when modifying input it gets messed up.
If that happens every key press will copy and insert current input alongside with pressed character.
Vital notes:
Encoding is set to UTF-8 in terminal(s)
Issue persists on different emulators ( Terminator, gnome-terminal )
Issue persists when using different Ruby runtime console ( IRB, Pry )
Issue appears to be related to Ruby runtime, NOT Linux shell (i guess...)
Issue appears since:
Since system install. Didn't appear on my MacBook Air
System:
ArchLinux, although coworker reported same thing happens on his MacBook Pro.
How to reproduce (works for me):
Open rails console
Type example code: Shift.where(name: "som").where(name: "dom").where(name: "pom")
Navigate cursor to modify first where statement.
Change "som" to "SOM"
Should see it break
Press random key repeatedly to see it break even more.
Images:
Good input
Now i will navigate to first where statement to change "som" to uppercase "SOM"
I basically navigated my cursor and pressed SHIFT+S, SHIFT+O, SHIFT+M
Hope it's clear enough :-)
Thank you!
EDIT 1:
Tried using zsh instead of bash, didn't help
Disabled spring gem, didn't help
EDIT 2:
Folks on reddit suggested that i should check if there are any Ruby readline warnings eg. "Readline is not installed". None of them appear anywhere. Also reinstalled ruby 2.4.1, seems like it's not the problem in my case.
EDIT 3:
I cannot reproduce the issue in a different Rails project.
Issue appears on Rails 5.1.1, meanwhile 5.0.3 works flawlessly.
Is it possible that Rails itself (or rather one of its gems) can be the cause?
I had a very similar issue, and I boiled it down to my coloring.
I had the following in my IRBRC:
class String
def _colorize(color_code)
"\e[#{color_code}m#{self}\e[0m"
end
def red
_colorize(31)
end
def yellow
_colorize(33)
end
end
IRB.conf[:PROMPT][:MY_PROMPT] = {
:AUTO_INDENT => true, # enables auto-indent mode
:PROMPT_I => "[ME]".red + " > ".yellow, # normal prompt
:PROMPT_S => "[ME]".red + " ".yellow, # prompt for continuated strings
:PROMPT_C => "[ME]".red + " * ".yellow, # prompt for continuated statement
:RETURN => "[ME]".red + "=> ".yellow + "%s\n".red # format to return value
}
IRB.conf[:PROMPT_MODE] = :MY_PROMPT
And when I removed the .red and .yellow, everything was just fine.
I think it's because my coloring characters like \e[31m was getting counted as a length 5 characters instead of 0 characters.
My solution was to remove my coloring for the time being. Hopefully someone will come up with a better solution than that.
I am extremely new to Informix and am having some trouble trying to get sqldemo installed.
Set up so far:
openSuse 12.1 (32 bit)
Informix Growth Edition 11.70 UC6
Informix SQL Developer 7.50 UC6
Informix RDS 7.50 UC6
Informix ID 7.50 UC6
After struggling a few days and a lot of reading of http://publib.boulder.ibm.com/infocenter/idshelp/v117/index.jsp, I managed to get Informix installed and On-line.
I also opted to install the demo database instance that comes with the installation.
I now and attempting to get started with Informix 4GL by Example.
I am trying to get the sqldemo database up. I don't know if it will replace the previous instance installed with Informix, but that is a different problem.
Right now as per the document, running the following should set up the DB:
sqldemo stores2t -log
I however get an error: "Invalid Locales set !!".
I have tried looking up this error and also in the documentation.
I have tried setting the CLIENT_LOCALE and DB_LOCALE in my .profile file.
For example:
export CLIENT_LOCALE=en_US.CP1252 and
export DB_LOCALE=en_US.819
This has not helped.
A push in the right direction, or perhaps some other documentation I could read that would explain things better would really be appreciated.
If any other information is required from me, please do not hesitate to ask.
Update 1
Thanks so much for the response.
A couple of things firstly that I have tried since your post.
Changed the the CLIENT_LOCALE and DB_LOCALE as you specified - Same error - So i removed it as you said it should not be set.
Fixed a problem in my PATH and made sure it has /usr/informix/bin - Same Error
INFORMIXDIR is /usr/informix
INFORMIXSERVER is ol_informix1170 (This is from the database that was installed with the informix install, don't know if this must be changed? and if so to what?)
Ran the script you mentioned, result :
INFORMIXDIR=/usr/informix
INFORMIXSERVER=ol_informix1170
INFORMIXSQLHOSTS=/usr/informix/etc/sqlhosts
LANG=en_US.UTF-8
ONCONFIG=onconfig
I noticed I had set the language to UK, which made the Locales en_gb instead if en_us, so tried changing that in my .profile, which did not help, so also tried changing the language to US and the locales to en_us, but this made no difference.
As for what you said about the sqldemo script and the already installed db, It is fine if that db is removed as this is just a test VB box for me to learn on.
Could the $INFORMIXSERVER set as ol_informix1170 be the problem?
Thank you once again for the help.
Neill
Update 2
Thanks again for the response.
A few things to note.
The dbenv results I posted is all that shows which i assume/presume (uh-oh) means that the other environment variables are not set. Which of the environment variables you posted are absolutely necessary for it to work?
As above, Where would I find the terminfo file, or does this need to be created?
As above, the SQLEXEC variable... where would I find sqlrm? I can somewhat remember from the documents I have read I think it should be $INFORMIXDIR/lib? but I only have an esql directory. Is this correct.
Barring that something in the first 3 above is not causing more problems, when trying your suggestion of DEMOPATH=en_us/0333 sqldemo stores2t -log I receive the following error:
Sorry, cannot read the mkstores3 program required to build the demonstration database. Check the /etc subdirectory of INFORMIXDIR (/usr/informix).
Checking /usr/informix/etc shows indeed that there is no mkstores3 file.
Attempting your further note of isqldemo, I get the following error:
/usr/informix/bin/isqldemo: line 58: /usr/informix/demo/sql/en_us/e01c/isqldemo: No such file or directory.
I guess this makes perfect sense as there is no e01c directory, just the 0333 directory.
Right now anything you can tell me would indeed be a consolation because my newb-ness to generally Linux and definately Informix is a big factor. Interesting that this bug has been around for so long. I guess way more experienced folk than I figured out how solve it on their own, or just never bothered with the sqldemo.
I guess that will teach me to read this:
INFORMIX-4GL by Example
Version 4.1
July 1991
Going to check now if any updated text exists, but would still appreciated more help in solving this problem. Do you think reverting to a previous snapshot before Informix was installed and not opting for the ol_informix1170 database to be included could be a possible solution? I wouldn't really see that it would be, but what do I know.
Many many thanks for your continued time and effort.
Regards,
Neill
Update 3
So I see indeed the document I was reading is ancient. I have found an updated one (2002) which uses a different script (dbaccessdemo7).
I tried running that, have run into an error, but tomorrow is another day.
For now I am going to mark this as solved because of the bug detected and resolved. I am not going to put more time and effort into sqldemo.
Thank you so much, and if I struggle with dbaccessdemo 7, I will post a new question.
Regards,
Neill
The sqldemo script won't create a new server; it may clobber your existing database (a single server may house multiple databases; indeed, there are 4 sys* databases created when a server is initialized) but it won't harm your server otherwise.
Probable cause of the error
The normal problem with invalid locales is that you've not set $INFORMIXDIR. You need $INFORMIXDIR set unless /usr/informix is (a symlink to) the correct location. You also need $INFORMIXSERVER set, and you usually need $INFORMIXDIR/bin on $PATH. Strictly, $INFORMIXSERVER is the only mandatory variable; in practice, you worry about the other two too.
The $INFORMIXDIR setting is used to locate the locale information (which is found in $INFORMIXDIR/gls) and the message files (which are found in $INFORMIXDIR/msg).
Note that CP1252 is a Windows code page. Normally on Unix, you'd either not set CLIENT_LOCALE or DB_LOCALE, or you could set them to:
export CLIENT_LOCALE=en_us.8859-1
export DB_LOCALE=en_us.8859-1
or you can choose another more appropriate (to you) locale. The 8859-15 locale includes the Euro symbol, for example, or the utf-8 locale dictates UTF-8 in the database. But, for initial debugging, stick with the 8859-1 locale, aka 819 or 0333 (all based on the IBM CCSID). If it doesn't work with 8859-1, then we have one set of problems; if it works with 8859-1 but not some other codeset or locale, then we have a different set of problems.
Follow-up info if the solution above fails
If that isn't the trouble, then I'll ask for some more details — notably, your Informix environment as reported by the dbenv script below:
: "#(#)$Id: dbenv.sh,v 2.11 2007/09/02 00:18:58 jleffler Exp $"
#
# Printout INFORMIX database environment
informix1="DB[^=]|DELIMIDENT=|SQL|ONCONFIG|TBCONFIG|INFOR"
informix2="ARC_|CLIENT_LOCALE=|GL_|GLS8BITSYS|CC8BITLEVEL|ESQL|FET_BUF_SIZE="
informix3="INF_ROLE_SEP=|NODEFDAC=|ONCONFIG|OPTCOMPIND|PDQ|PSORT"
informix4="PLCONFIG|SERVER_LOCALE|FGL|C4GL|NE_"
informix5="TCL_LIBRARY|TK_LIBRARY"
informix="$informix1|$informix2|$informix3|$informix4|$informix5"
system="COLLCHAR=|LANG=|LC_|LD_LIBRARY_PATH(_64)?=|PATH=|SHLIB_PATH="
jlss="IXD(32|64)?="
env |
egrep "^($informix|$system|$jlss)" |
sort
It's an old script; that's why the shebang is missing.
Second set of diagnosis
I was hoping for the complete output of the dbenv script; it is surprising how often something shows up. However, given what you've said, it is likely to be OK.
The INFORMIXSERVER setting sounds fine.
I'm struck by the LANG=en_US.UTF-8 setting; Informix does pay attention to $LANG and the $LC_* variables (that's why dbenv prints those out). That may be a factor in the problem. However, I would have expected CLIENT_LOCALE and SERVER_LOCALE to deal with that if it was the problem. Also, on my Mac, I have LANG=en_US.UTF-8 and yet I can connect to (8859-1) databases OK.
This is beginning to look like an install problem...or sqldemo problem...
I transitioned from a Mac to a RHEL 5 (archaic) x86/64 machine, and tried running sqldemo over there:
$ dbenv
DBDATE=Y4MD-
DBEDIT=vim
INFORMIXDIR=/work4/informix/tools-7.50.FC4
INFORMIXSERVER=toru_31
INFORMIXSQLHOSTS=/work4/informix/ids-11.70.FC4/etc/sqlhosts
INFORMIXTERM=terminfo
IXD64=/work4/informix/ids-11.70.FC4
IXD=/work4/informix/tools-7.50.FC4
IXH=/work4/informix/ids-11.70.FC4/etc/sqlhosts
IXO=/work4/informix/ids-11.70.FC4/etc/onconfig.toru_31
IXS=toru_31
LANG=en_US.UTF-8
LD_LIBRARY_PATH=/lib64:/usr/lib64:/work4/informix/tools-7.50.FC4/lib:/work4/informix/tools-7.50.FC4/lib/tools:/work4/informix/tools-7.50.FC4/lib/esql:/work4/informix/ids-11.70.FC4/lib:/work4/informix/ids-11.70.FC4/lib/esql:/work4/informix/ids-11.70.FC4/lib/cli
ONCONFIG=onconfig.toru_31
PATH=/work4/informix/tools-7.50.FC4/bin:.:/work4/jleffler/bin:/u/jleffler/bin:/work4/informix/ids-11.70.FC4/bin:/u/jleffler/linux/x86_64/bin:/work4/informix/11.70.FC1:/usr/atria/bin:/work4/jleffler/perl/v5.12.1/bin:/usr/bin:/bin:/usr/X11R6/bin:/atria_release/cm_dist/vobs/imitools/bin:/opt/rational/clearcase/bin:/opt/rational/clearquest/bin
SQLCMDLOG=/work4/jleffler/.sqlcmdlog
SQLEXEC=sqlrm
TERMINFO=/work4/jleffler/terminfo
TERM=xterm-color
$ sqldemo st2 -log
Invalid Locales set !!
$
Oh yeah? No; my locales are fine, thank you!
Well, so be it...I can reproduce your problem! That's step 1. Step 2 is to look at the expletive deleted script.
PRODUCT=sql
DEMOFILE=sqldemo
DEFLANG=en_US.8859-1
INFORMIXDIR=${INFORMIXDIR:=/usr/informix}
INFENV=$INFORMIXDIR/bin/infenv
CONVLOC=$INFORMIXDIR/bin/convloc
if [ $# -gt 0 -a "X$1" = "X-e" ] ; then
LOCALE=$DEFLANG # -e means en_US.8859-1 required
shift
else
LOCALE=`$INFENV DBLANG` # get DBLANG value
if [ "x${LOCALE}" = "x" ]; then
LOCALE=`$INFENV CLIENT_LOCALE` # try CLIENT_LOCALE instead
if [ "x${LOCALE}" = "x" ]; then
LOCALE=`$INFENV DB_LOCALE` # finally default to DB_LOCALE
fi
fi
fi
if [ "x${LOCALE}" = "x" ]; then
LOCALE=$DEFLANG # finally default to DB_LOCALE
fi
export LOCALE
if [ "x${DEMOPATH}" = "x" ]; then
echo "Invalid Locales set !!"
else
exec $INFORMIXDIR/demo/$PRODUCT/$DEMOPATH/$DEMOFILE $*
fi
exit $?
Note that test for ${DEMOPATH}; note that DEMOPATH is not set in the script. So, we've got to get it set. What to? Well, ls $INFORMIXDIR/demo/sql shows that there are various locale-specific sub-directories (en_us,
ja_jp,
ko_kr,
th_th,
zh_cn,
zh_tw) and under the en_us directory there's 0333 (only).
Please run:
DEMOPATH=en_us/0333 sqldemo stores2t -log
This more or less worked for me — I believe it would work for you. I have a slightly unusual setup in that I have just I4GL (p-code and c-code) and ISQL in the $INFORMIXDIR; the server is run out of a different directory. This means I don't have server utility programs like dbload (specifically) in $INFORMIXDIR/bin. When the sqldemo script tried to load the data with dbload, therefore, it failed for me. It would work for you because you have all the Informix software in a single directory. To add insult to injury, it runs the dbload program by explicit path, so I can't futz my PATH to make it available.
This should get you going. I have a bug to report...it is CQ idsdb00244894.
I'm sorry that you ran into so much trouble. You shouldn't have done so.
I recently had to move my site from one server to another and it appears Fred's 3Drotate script creates files that have Imagemagick settings in them instead of image data. When I first ran the script I received the following error:
expr: warning: unportable BRE: `^[0-9][0-9]*$': using `^' as the first character of the basic regular expression is not portable; it is being ignored
expr: warning: unportable BRE: `^[+-][0-9][0-9]*$': using `^' as the first character of the basic regular expression is not portable; it is being ignored
expr: warning: unportable BRE: `^[0-9]*[\\.][0-9]*$': using `^' as the first character of the basic regular expression is not portable; it is being ignored
expr: warning: unportable BRE: `^[+-][0-9]*[\\.][0-9]*$': using `^' as the first character of the basic regular expression is not portable; it is being ignored
I was able to resolve this by removing each instance of the '^' character. The script runs and it creates a file of a few hundred KB, but the contents appear to be a configuration such as:
id=MagickCache
quantum-depth=16
class=DirectClass colors=0 matte=False
columns=500 rows=500 depth=8
colorspace=sRGB
compression=JPEG quality=75
units=PixelsPerInch
resolution=72x72
page=500x500+0+0
rendering-intent=Perceptual
gamma=0.454545
red-primary=0.64,0.33 green-primary=0.3,0.6 blue-primary=0.15,0.06
white-point=0.3127,0.329
date:create=2012-08-10T20:44:21-07:00
date:modify=2012-08-10T20:44:21-07:00
jpeg:colorspace=2
jpeg:sampling-factor=2x2,1x1,1x1
Any ideas? I'm running imagemagick version 6.7.8-9 which is newer than what was on my original server, however I don't know which version that was.
Update:
I'm on a CentOS box using 3DRotate revised by Fred on 3/11/10. ImageMagick is version 6.7.8-9 whereas my old server, also CentOS was using version 6.7.6-0.
Fred's 3Drotate script still works fine for me. I have no reason to complain.
This is on Mac OS X Lion, with Bash version GNU bash, Version 4.2.37(2)-release....
You are strongly advised to re-download the script and try again. If you want to report a bug, you should give info about your OS, your Bash and your ImageMagick versions...
Oh, and see also this page, which states...
...you need ImageMagick v6.3.5.0 or higher for the script to work,
...gives some hints about troubleshooting and
...tells you the eMail address of the author so you can contact him to discuss your problems.
With recent changes to ImageMagick between IM 6.7.6.7 and IM 6.7.8.3 for colorspace changes and grayscale becoming linear, I have had to go through recently all my scripts and make appropriate changes. I am only part way through my scripts as of this date, but have fixed about 1/3 to 1/2, but 3Drotate did not need any changes since the last one on 11/26/2011. But your version is to old, so you will need to get an update. The problems you seem to have may or may not be related. But appear to be related to the unix utility expr. I would make sure that you have a current version of that installed. The following works perfectly fine for me on both IM 6.7.6.0 and 6.7.8.9 on my Mac OSX Snow Leopard
3Drotate pan=45 tilt=45 auto=zc mandril.jpg mandril_test.jpg
The first question I would ask is what was your exact command line. As you can see the arguments are a bit different from my other scripts as they include equal signs.
If you still have trouble, report them to me or on the ImageMagick Discourse forum at http://www.imagemagick.org/discourse-server/viewforum.php?f=1
Fred