I don't know what is ^I and ^G in a Pascal program.
Here:
const TAB = ^I;
and
WriteLn(^G, ' Error : ' , s, ' . ' );
In that context, ^ stands for the Ctrl key on the keyboard. To demonstrate, go to a CMD prompt and press Ctrl and G at the same time.
The other usage is as indicated in the other answer, i.e. as an indirection operator for pointers.
caret(^) is for a pointer variable.
Read more
Related
I want to be able to paste file paths into cmd with em dashes (—, alt 0151) in them.
cmd converts them to ones where the em dashes have been replaced by a hyphen.
Manual input:
(Keyboard) D:\—\image.png
(cmd) D:\—\image.png
Entering this would open the file as expected.
Pasted input:
(Clipboard) D:\—\image.png
(cmd) D:\-\image.png
Entering this would give me an error because a directory named hyphen doesn't exist.
This is baffling because the file system supports paths to have such a character - I can access this file if I type the path manually, and programs can open it just fine.
Why convert a character that is supported? If it wasn't supported when the conversion was added, why not remove the conversion when the support was added?
More importantly, how can I work around this while keeping the em dashes? I have programs that depend on such paths and it'd be inconvenient to change them in all of them.
Similar to:
How to deal with an em dash in a filename
Using “En Dash” in an input file to a batch file
Rename Files having EmDash using a Batch File
Changing the code page made no difference.
My workaround was to create an AutoHotKey script to parse the path being pasted and to send alt 0151 whenever it encounters an em dash.
It could be faster, but it works - which is miles better than receiving an error.
#SingleInstance, force
numpad7::
tooltip, exited!
Clipboard := stored
sleep, 300
exitapp
#IfWinActive ahk_exe cmd.exe
$^v::
cliptext := clipboard
stored := ClipboardAll
StringGetPos, garbage, cliptext, —
garbage =
if !ErrorLevel {
Loop, Parse, cliptext
{
char = %A_LoopField%
If (char == "—") {
clipboard := sentence
sendinput, ^v
SendInput {alt down}{numpad0}{numpad1}{numpad5}{numpad1}{alt up}
sentence := ""
} else if (char == "") {
char := " "
gosub define_sentence
} else {
gosub define_sentence
}
}
; send sentence when EOL
gosub define_sentence
Clipboard := sentence := SubStr(sentence, 1, -1)
sendinput, ^v
sleep 200
Clipboard := stored
stored =
sentence =
return
} else {
sendinput, ^v
}
return
define_sentence:
sentence := sentence . char
tool := "s= " . sentence . "`n" . "c= " . char
tooltip, %tool%
return
On another note, the highlight.js for autohotkey doesn't seem to work which is great.
string s;
while(getline(cin,s)){
cout << "---" << endl
for(auto c: s) cout << int(c) << endl;
}
cout << "Exiting";
If my input is Ctrl+Z, then I press enter once, and my program exits immediately.
^Z
Exiting
If I enter a character before pressing Ctrl+Z, then I have to press enter twice, and my program does not exit.
s^Z
---
115
26
I had always interpreted Ctrl+Z as the EOF character. getline would continue until it reaches this character, at which point getline tests false and my program would exit. I'm curious why my program interprets Ctrl+Z as the substitute character 26, depending on whether there is a preceding character or not, and why it was necessary for me to press Enter twice in the second example?
26 is code of ^Z on your platform , and ^Z is a EOF marker for terminal, that's true. Characters with codes less than 32 are control characters for ASCII -compatible platform, I hope you know that. 26 isn't a substitute character, it's actual control code, ^Z or some "bug" character are substitutes. getline reads input until EOL (end-of-line, designated as CR by ASCII) or EOF (end of file, end of stream, designated as SUB) is encountered in stream, so ^Z is read with the second call of getline. That behavior is absolutely correct.
It is defined by platform (or, more precisely, by terminal type) if characters are sent to input buffer immediately or after some flush command occurred. Usual cause of buffer flush is EOL character, that's your ENTER (CR - Carriage return). Tat's why program receives EOF after Enter in your case. Note that some platform use LF (line feed) as EOL, and some - a pair of LF+CR. C literal '\n' is to be correctly translated into particular EOL marker.
Note, that you can use different delimiter:
template< class CharT, class Traits, class Allocator >
std::basic_istream<CharT,Traits>& getline(
std::basic_istream<CharT,Traits>& input,
std::basic_string<CharT,Traits,Allocator>& str,
CharT delim );
ASCII table with substitute Control+ :
I have not used Visual FoxPro for a while. Today, my ex-colleague asks me how to remove non character from name field, i.e. only a-z and A-Z are allowed. I remember I used a function called strstran to do it. I needed to define a variable contains a-z and A-Z. But I do not remember now. Does someone knows how to handle this problem. Thanks in advance.
Use the CHRTRAN() function.
FUNCTION GetAlphaCharacters
LPARAMETERS tcExpressionSearched
LOCAL lcAllowedCharacters
m.lcAllowedCharacters = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"
RETURN CHRTRAN(m.tcExpressionSearched, CHRTRAN(m.tcExpressionSearched, m.lcAllowedCharacters, ""), "")
ENDFUNC
Another option is to use ISALPHA(). This only looks at the left most position in the string but it's not case sensitive.
***This should work, but I haven't tested it.
myresults = ""
myvar = "MyText12"
FOR(i = 1 TO LEN(myvar))
IF ISALPHA( SUBSTR(myvar, i, 1) )
myresults = myresults + SUBSTR(myvar, i, 1)
ENDIF
ENDFOR
RETURN myresults
I know I'm a bit late to the party, but here is a function I wrote to clean out all non-printable ASCII characters from a character string.
CLEAR
* Contains ASCII characters 1 (SOH) and 2 (STX)
cTest = "Garbage Data "
? cTest
cTest = RemoveNonPrintableCharacters(cTest)
? cTest
FUNCTION RemoveNonPrintableCharacters
LPARAMETERS tcExpressionSearched
cCleanExpression = tcExpressionSearched
* Cleans out the first 32 ASCII characters, which are not printable
FOR decCount = 0 TO 31
cCleanExpression = CHRTRAN(m.cCleanExpression, CHR(decCount), "")
ENDFOR
* Also cleans out the non-printable DEL character (ASCII 127)
cCleanExpression = CHRTRAN(m.cCleanExpression, CHR(127), "")
* Return the clean string
RETURN cCleanExpression
ENDFUNC
I've tried this:
main = do
hSetBuffering stdin NoBuffering
c <- getChar
but it waits until the enter is pressed, which is not what I want. I want to read the character immediately after user presses it.
I am using ghc v6.12.1 on Windows 7.
EDIT: workaround for me was moving from GHC to WinHugs, which supports this correctly.
Yes, it's a bug. Here's a workaround to save folks clicking and scrolling:
{-# LANGUAGE ForeignFunctionInterface #-}
import Data.Char
import Foreign.C.Types
getHiddenChar = fmap (chr.fromEnum) c_getch
foreign import ccall unsafe "conio.h getch"
c_getch :: IO CInt
So you can replace calls to getChar with calls to getHiddenChar.
Note this is a workaround just for ghc/ghci on Windows. For example, winhugs doesn't have the bug and this code doesn't work in winhugs.
Might be a bug:
http://hackage.haskell.org/trac/ghc/ticket/2189
The following program repeats inputted characters until the escape key is pressed.
import IO
import Monad
import Char
main :: IO ()
main = do hSetBuffering stdin NoBuffering
inputLoop
inputLoop :: IO ()
inputLoop = do i <- getContents
mapM_ putChar $ takeWhile ((/= 27) . ord) i
Because of the hSetBuffering stdin NoBuffering line it should not be necessary to press the enter key between keystrokes. This program works correctly in WinHugs (sep 2006 version). However, GHC 6.8.2 does not repeat the characters until the enter key is pressed. The problem was reproduced with all GHC executables (ghci, ghc, runghc, runhaskell), using both cmd.exe and command.com on Windows XP Professional...
Hmm.. Actually I can't see this feature to be a bug. When you read stdin that means that you want to work with a "file" and when you turn of buffering you are saying that there is no need for read buffer. But that doesn't mean that application which is emulating that "file" should not use write buffer. For linux if your terminal is in "icanon" mode it doesn't send any input until some special event will occur (like Enter pressed or Ctrl+D). Probably console in Windows have some similar modes.
The Haskeline package worked for me.
If you need it for individual characters, then just change the sample slightly.
getInputLine becomes getInputChar
"quit" becomes 'q'
++ input becomes ++ [input]
main = runInputT defaultSettings loop
where
loop :: InputT IO ()
loop = do
minput <- getInputChar "% "
case minput of
Nothing -> return ()
Just 'q' -> return ()
Just input -> do outputStrLn $ "Input was: " ++ [input]
loop
From comment of #Richard Cook:
Use hidden-char: Provides cross-platform getHiddenChar function.
I used the haskeline package, suggested in other answers, to put together this simple alternative to getChar. It requests input again in the case that getInputChar returns Nothing. This worked for me to get past the issue; modify as needed.
import System.Console.Haskeline
( runInputT
, defaultSettings
, getInputChar
)
betterInputChar :: IO Char
betterInputChar = do
mc <- runInputT defaultSettings (getInputChar "")
case mc of
Nothing -> betterInputChar
(Just c) -> return c
Q1: What does this mean: WriteLn (#$0b)?
$0b should hexadecimal like 0x0b, but what about the # sign?
Q2:
x:=readkey;
if ( x = #5) do...
Does #5 mean five? Then what is the# sign for?
Many thanks.
The # in front of a number represents a character with the indicated value (both decimal, and hex numbers preceded by a $, are accepted). So #5 is the same as chr(5), or CtrlE.
Ah, memories ...
#x is indeed the equivalent of chr(x), like Greg Hewgill said.
I'd like to add a little info.
Extended keys, ie the arrow keys, send zero and the char's code:
ch := ReadKey;
if ch = #0 then
begin // extended key
ch := ReadKey; // <-- read again to get the actual code
end else ...