Some of you may be familiar with Parenthesis Hell (code here). Well, nice way to waste some time between evening phone calls, right?
I successfully used ghc to compile these five files. The interpreter seems to work if I run
$ ./ph
But since I don't really understand Lisp/cdr/car stuff very well, I quickly ran into trouble trying to do a functioning program. I thought at least some of them were supposed to print something to standard output...
$ ./ph () ()
-bash: syntax error near unexpected token `)'
$ ./ph () (3)
$ ./ph () (())
$
$ ./ph (()())
-bash: syntax error near unexpected token `('
$ ./ph "()()" # suggestion in comment
ph: ()(): openFile: does not exist (No such file or directory)
$ ./ph # actual behavior with returns
()
()
ph: Prelude.read: no parse
Needless to say, any attempt at using the Hello World in the "doc" led to lots of "syntax error near unexpected token" messages. Any ideas? Or does everything evaluate to nil and so this is just an elaborate Lisp joke, except with two actual compilers? Thanks!
(Note: Lisp aficionados will be doing a service by teaching more people about how to interpret this parenthesis stuff, which I have to admit will be useful for me anyway in a completely different context.)
Edit 2: #dfeuer at least has a resolution which worked, though I do wonder whether it is possible to use interactively from the shell.
$ cat hello
(()()(()()(()()()()((()()(()(()((()((()()()((()((()()()((()((((()()(()()()()()()(((()(((()((()((((()(((()()(()()((()((()()()((()()(()()()()(()()()()(()()()()(()(())))))))))))))))))))))))))))))))))))))))))))))))))
$ ./ph hello
Hello world!
Bizarre and yet awesome.
I don't think it expects code in its arguments. It looks to me like it looks for filenames (and a command line option named -v).
It also seems like it only accepts one parenthesized expression per program. So something like () (()) would be invalid but (() (())) would be okay (or at least well-formed). If you wanted to use this from the command line, you could use echo since it also reads from stdin:
echo "(()()(()()(()()()()((()()(()(()((()((()()()((()((()()()((()((((()()(()()()()()()(((()(((()((()((((()(((()()(()()((()((()()()((()()(()()()()(()()()()(()()()()(()(())))))))))))))))))))))))))))))))))))))))))))))))))" | ./Test
Related
I am running a simple linux system with busybox and hush as the shell.
When I try to run the standard "./configure" for compiling programs, I always get the following error:
/Programs/blazeos/build/bison-3.4.1 # ./configure
hush: ambiguous redirect
hush: syntax error at 'fi'
If I run it with "ash ./configure" it runs without any problems, so it seems to be related to the hush shell. Does anyone know why this is happening or how I can debug it? I have tried it with several different source packages, such as "flex", "bison", "m4" etc. and I always get the same error.
This happens in as_fn_error:
as_fn_error ()
{
as_status=$1; test $as_status -eq 0 && as_status=1
if test "$4"; then
as_lineno=${as_lineno-"$3"} as_lineno_stack=as_lineno_stack=$as_lineno_stack
$as_echo "$as_me:${as_lineno-$LINENO}: error: $2" >&$4
fi
$as_echo "$as_me: error: $2" >&2
as_fn_exit $as_status
} # as_fn_error
This happens because >&$4 (getting the file descriptor number to redirect to by evaluating $4) is not supported in hush. Arguably, this violates the letter of the POSIX sh standard; bolding for emphasis is mine:
The redirection operator: [n]>&word shall duplicate one output file descriptor from another, or shall close one. If word evaluates to one or more digits, the file descriptor denoted by n, or standard output if n is not specified, shall be made to be a copy of the file descriptor denoted by word
As I read the specification, "evaluates to" means that expansions should be run, so using a parameter expansion should be legal in that location. Thus, this is (arguably) a missing feature in hush that would be required for standards compliance.
If you're interested in trying to work around the issue, in all the cases where this optional parameter is used, it's given a hardcoded value of 5. Thus, you could simply change >&$4 to >&5, and this specific error would be avoided.
This is really just out of curiosity.
A typo made me notice that in Bash, the following:
$ .anything
does not print any error ("anything" not to be interpreted literally, it can really be anything, and no space after the dot).
I am curious about how this is interpreted in bash.
Note that echo $? after such command returns 127. This usually means "command not found". It does make sense in this case, however I find it odd that no error message is printed.
Why would $ anything actually print bash:anything: command not found... (assuming that no anything cmd is in the PATH), while $ .anything slips through silently?
System: Fedora Core 22
Bash version: GNU bash, version 4.3.39(1)-release (x86_64-redhat-linux-gnu)
EDIT:
Some comments below indicated the problem as non-reproducible at first.
The answer of #hek2mgl below summarises the many contributions to this issue, which was eventually found (by #n.m.) as reproducible in FC22 and submitted as a bug report in https://bugzilla.redhat.com/show_bug.cgi?id=1292531
bash supports a handler for situations when a command can't be found. You can define the following function:
function command_not_found_handle() {
command=$1
# do something
}
Using that function it is possible to suppress the error message. Search for that function in your bash startup files.
Another way to find that out is to unset the function. Like this:
$ unset -f command_not_found_handle
$ .anything # Should display the error message
After some research, #n.m. found out that the described behaviour is by intention. FC22 implements command_not_found_handle and calls the program /etc/libexec/pk-command-not-found. This program is part of the PackageKit project and will try to suggest installable packages if you type a command name that can't be found.
In it's main() function the program explicitly checks if the command name starts with a dot and silently returns in that case. This behaviour was introduced in this commit:
https://github.com/hughsie/PackageKit/commit/0e85001b
as a response to this bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=1151185
IMHO this behaviour is questionable. At least other distros are not doing so. But now you know that the behaviour is 100% reproducible and you may follow up on that bug report.
I'm currently trying to solve a tricky/silly challenge and i've come to a dead end.
The challenge is basically to form a one-liner /bin/sh compatible command line
which essentially outputs "Hello World" without directly typing White space or Tab characters in the command itself.
for example something like -
echo Hello World
would be invalid since we used white space twice in the command line.
Any ideas?
Assuming that IFS by default is set to space:
# echo${IFS}a${IFS}b
a b
Tested on Solaris 10 sh.
Cheating a little, but it gives the correct effect (superficially) in bash:
PS1=hello$'\x20'world$'\n'"$PS1"
for example,
$ PS1=hello$'\x20'world$'\n'"$PS1"
hello world
$
The problem is that it will print hello world after every command in future :-)
I have a bit of code in my haskell program like so:
evaluate :: String -> IO ()
evaluate = ...
repl = forever $ do
putStr "> " >> hFlush stdout
getLine >>= evaluate
Problem is, when I press the delete key (backspace on windows), instead of deleting a character from the buffer, I get a ^? character instead. What's the canonical way of getting delete to delete a character when reading from stdin? Similarly, I'd like to be able to get the arrow keys to move a cursor around, etc.
Compile the program and then run the compiled executable. This will give the correct behavior for the Delete key. For some reason interpreting the program screws up the use of Delete.
To compile the program, just invoke ghc like this:
$ ghc -O2 myProgram.hs
This will generate a myProgram executable that you can run from the command line:
$ ./myProgram
That will then give the correct behavior for Delete.
I have developed a haskell application which is tested with WinHugs interpreter working fine .. when i try to comiple the same application using WinGHCi it prompts a error
lexical error in string/character literal at character '\t'
I have used \t in IO Program to display text
Example :- putStr "\n \n \t \t Hello ! "
Any solutions ?
You may want to try this step-by-step guide:
Save your program in a file program.hs this file should contain a function main of the type IO () that is executed at the program's start.
Open a shell in the directory where this file is.
Type ghc -O3 --make program.hs to compile program.hs into an executable program.exe.
Try to run program.exe
If the error still occurs, please post some more code to aid debugging.