read_line_to_codes Prolog swipl strange behaviour - input

I want to read user name and display it with capital letter, i made something like that.
notice:-
write('Hi whats ur name?'), nl,
read_line_to_codes(user_input,Codes1),
capitalize(Codes1,Codes2)
->
atom_codes(Name,Codes2),
write(Name).
capitalize([],[]).
capitalize([H1|T], [H2|T]):-
code_type(H2, to_upper(H1)).
I dont understand the problem it seems, like user_input is empy and without any reading executes.
Whats even stranger this one seems to work well...
notice:-
write('Hi whats ur name?'), nl,
read(Name),
write(Name).
This image describes problem well...

How exactly are you running this code to test it?
The first version of your code works fine for me in the SWI-Prolog shell:
?- notice.
Hi whats ur name?
|: isabelle
Isabelle
true.
It also works fine when started as a "standalone" program:
$ swipl -s foo.pl -q -t notice
Hi whats ur name?
|: isabelle
Isabelle
(Although you should add a newline after the output.)

Related

Setting ft=vb causing vim's parenthesis matching to stop working

I'm having a weird issue in which I can't get parentheses to match in VB files in vim or gvim.
For example, if I start vim and insert Iif(test, 0, 1), I can use % to jump between the two parentheses like normal. Then if I run :set ft=vb, it stops working. Actually, I get one more jump, then it stops working.
I have tested this on two different machines running Windows and Linux and I get the same results.
Does anyone know why this might be?
You're using the matchit plugin that comes with Vim. In $VIMRUNTIME/ftplugin/vb.vim, it defines custom pairs (e.g. If...End If) which override the default pairs. To re-enable those (in addition), put the following into ~/.vim/after/ftplugin/vb.vim:
let b:match_words .= ',(:)'
Cp. :help b:match_words.

Batch Program Produces Strange Unexpected Output

Before I remembered how to accomplish what I was doing, I tried a couple different things, kind of just hacking at it.
What I was trying to accomplish was to set the following string as a variable and then echo it out in a batch script:
<?php require('__php__.php'); ?>
I eventually worked it out with help from SO, but before I got there, I tried this (for some reason):
set (phpStr=<? php require('__php__.php'); ?>)
Which I realize doesn't make any sense. However, how the cmd shell interpreted what I wanted to do was as follows:
set (phpStr= php require('__php__.php'); ? 0<? 1>)
In other words, when I typed the code in the second code block above, and turned on echo in the script, what showed up in the cmd shell was the command in the third code block. Then there was a syntax error, and the script exited.
Can anyone explain what happened? (Not why it didn't work. That is obvious to me, but rather, how it arrived at the interpretation it did. It's a pretty awesome restructuring of the original command. I just can't figure out how it got there.)
You need to escape redirection and other poison characters with ^ or the redirection will be active and try to create files etc. % is a special case.
You can also use something like this:
#echo off
for /f "delims=" %%a in ("<?php require('__php__.php'); ?>") do echo %%a

Zsh trouble when using echo with color/formatting characters

I'm just switch to zsh and now adapting the alias in which was printing some text (in color) along with a command.
I have been trying to use the $fg array var, but there is a side effect, all the command is printed before being executed.
The same occur if i'm just testing a echo with a color code in the terminal:
echo $fg_bold[blue] "test"
]2;echo "test" test #the test is in the right color
Why the command print itself before to do what it's supposed to do ? (I precise this doesn't happen when just printing whithout any wariable command)
Have I to set a specific option to zsh, use echo with a special parameter to get ride of that?
Execute the command first (keep its output somewhere), and then issue echo. The easiest way I can think of doing that would be:
echo $fg[red] `ls`
Edit: Ok, so your trouble is some trash before the actual output of echo. You have some funny configuration that is causing you trouble.
What to do (other than inspecting your configuration):
start a shell with zsh -f (it will skip any configuration), and then re-try the echo command: autoload colors; colors; echo $fg_bold[red] foo (this should show you that the problem is in your configuration).
Most likely your configuration defines a precmd function that gets executed before every command (which is failing in some way). Try which precmd. If that is not defined, try echo $precmd_functions (precmd_functions is an array of functions that get executed before every command). Knowing which is the code being executed would help you search for it in your configuration (which I assume you just took from someone else).
If I had to guess, I'd say you are using oh-my-zsh without knowing exactly what you turned on (which is an endless source of troubles like this).
I don't replicate your issue, which I think indicates that it's either an option (that I've set), or it's a zsh version issue:
$ echo $fg_bold[red] test
test
Because I can't replicate it, I'm sure there's an option to stop it happening for you. I do not know what that option is (I'm using heavily modified oh-my-zsh, and still haven't finished learning what all the zsh options do or are).
My suggestions:
You could try using print:
$ print $fg_bold[red] test
test
The print builtin has many more options than echo (see man zshbuiltins).
You should also:
Check what version zsh you're using.
Check what options (setopt) are enabled.
Check your ~/.zshrc (and other loaded files) to see what, if any, options and functions are being run.
This question may suggest checking what TERM you're using, but reading your question it sounds like you're only seeing this behaviour (echoing of the command after entry) when you're using aliases...?

Objective C Command Line Tool Argument Input

I have a bad problem and I hope you can give me some ideas! :)
What I want to do:
Simply read the user argument of the Script.
What is the problem:
special characters
Let me explain:
Scriptname: testscript
if the user types testscript -f filename.txt it prints out the name. Pretty easy.
But if the user types the following, it does not work for the shell: testscript -f file(somethings)name.txt
so if there are special characters, it always throws an sh: error....
Working: it works if the user writes this: testscript -f 'filename(something).txt'
with ' '
But this is inconvenient and often people forget that they have to write it.
Does anyone have an idea what I can do?
I thought about getting the argument and then add ' and ' at the beginning and end, I am not sure if the shell error is first..
Otherwise, does anyone have an idea!?
Would it be possible to check if there is an () somewhere in the filename before allowing userinput and remove () then?
Unfortunately, there's nothing your program can really do here - the error your users are seeing comes from the shell, before your program even has a chance to execute.

How do you quit the Vi editor with single keypress?

Because honestly
:wq!
is just too much to type.
Please note that the question is about original Vi (say Vi which comes with FreeBSD) not Vim.
Hold down the shift key and bang on Z twice.
ZZ is (mostly) equivalent to :wq!.
If you really want a single-keystroke solution, FreeBSD comes with the source so, in a pinch, you could modify that and re-compile. It's a bit of an overkill but it'll solve your problem.
What about "ZZ"? It has slightly different semantics to ":wq!", but is also slightly shorter.
This seems to work on solaris' old version of vi:
Version SVR4.0, Solaris 2.5.0
$ vi -c "map g ZZ" test
edit: Also, this seems to work:
$ vi -c 'map g :q!^M' test
Where ^M is actually, ^V (ctl-v) then ^M (ctl-m)
Map your favourite key to the :wq! command.
e.g. put this in your .vimrc:
map <F8> :wq!<CR>
Et voilá.
Edit:
Sorry, vim only, missed that.
Does :x work on Vi? Although for your case I guess it might be :x!
If you're using gvim you can close it with ALT+F4. Two keys, but one keypress.
If you're using vi in its own xterm, ALT+F4 should close the xterm, killing vi as well.
What's wrong with the tried and true?
:x
It's not one key press, but it's much less than :wq! which is what your question appears to truly seek.
Or is this a ViM only feature? My apologies if so.