1:09 AM
Oh. Well, I'm interested in specifically how an application can affect the meaning of control characters.
Like, if nothing is done to treat the form-feed character specially, then entering it as Ctrl+L has the same effect as entering it as Ctrl+V Ctrl+L.
But if something is done to treat it specially, then entering it as Ctrl+L gets the special treatment and Ctrl+V Ctrl+L (as before) uses it literally.
So the behavior here is provided by the terminal, and programs (including through libraries like Readline) can configure the terminal to give special behavior to particular characters.
What I'm not clear on, pun intended, is how one tells a terminal to treat any character as meaning the terminal (rather than the current line or the most recent character) should be cleared.
@EliahKagan To clarify,
stty
is not specific to Readline or Bash, and j
gets the special behavior even in child processes that are not shells. (stty
affects its controlling terminal, not any shell.)
@EliahKagan Interactive bash shells use Readline, which provides interactive editing and tab completion, and which is why
~/.inputrc
affects the behavior of Bash. In contrast, for example, Dash doesn't use Readline nor anything else providing similar functionality, and pressing the left arrow key while typing a command in Dash doesn't move the cursor to the left.
Although both
Char
and String
support \u
escape sequences, including the \u{
}
form to specify one character, String
supports \u{
}
with multiple hexadecimal code points inside the braces and separated by whitespace.
3:02 AM
3:18 AM
@Zanna One way to try out
printf
, sprintf
, or %
is to write a program that outputs a (properly aligned) multiplication table.
2 hours later…
5:13 AM
5 hours later…
10:22 AM
$ crystal eval 'puts "Hello, world!"' >/dev/full Unhandled exception: Error writing file: No space left on device (IO::Error) from ../../../../usr/share/crystal/src/io/evented.cr:82:13 in 'unbuffered_write' from ../../../../usr/share/crystal/src/io/buffered.cr:217:5 in 'flush' from ../../../../usr/share/crystal/src/io/buffered.cr:178:7 in 'write_byte' from ../../../../usr/share/crystal/src/char.cr:775:9 in 'to_s' from ../../../../usr/share/crystal/src/io.cr:174:5 in '<<' from ../../../../usr/share/crystal/src/io.cr:188:5 in 'print'
That does not throw an exception (and it prints no text to standard error and exits indicating success).
$ crystal eval 'print "Hello, world!\n"' >/dev/full Unhandled exception: Error writing file: No space left on device (IO::Error) from ../../../../usr/share/crystal/src/io/evented.cr:82:13 in 'unbuffered_write' from ../../../../usr/share/crystal/src/io/buffered.cr:144:9 in 'write' from ../../../../usr/share/crystal/src/io.cr:470:7 in 'write_utf8' from ../../../../usr/share/crystal/src/string.cr:4789:5 in 'to_s' from ../../../../usr/share/crystal/src/io.cr:174:5 in '<<' from ../../../../usr/share/crystal/src/io.cr:188:5 in 'print'
It seems that standard output is line buffered, so printing a newline flushes the buffer, and it is when the buffer is flushed that the attempt to actually write the file is made, which fails.
puts
, as well as print
with a newline character, prints a newline. print
without a newline character doesn't (though it would still cause the buffer to be flushed one or more times if the string passed to it were big enough).
Without a newline, the buffer is flushed during normal program termination when the file descriptor is closed, but that's after the method call to
print
has successfully completed.
Standard output is only typically line buffered by default when it is a terminal. Otherwise it's usually fully buffered. That's in C. But I don't expect Crystal to be different.
11:30 AM
5 hours later…
4 hours later…
9:06 PM
@Zanna It's no surprise that it supports nesting, since it uses the same syntax as string interpolation in Ruby, which does:
But I'm accustomed to Python, where nesting is not allowed because the syntax for string interpolation is different from that of ordinary expressions:
>>> f'{"x"}' 'x' >>> f'{'x'}' File "<stdin>", line 1 f'{'x'}' ^ SyntaxError: invalid syntax >>> f'{"{'x'}"}' File "<stdin>", line 1 f'{"{'x'}"}' ^ SyntaxError: invalid syntax
9:27 PM
« first day (1046 days earlier) ← previous day next day → last day (1353 days later) »