[HN Gopher] Do not use redirection characters in your shell prompt
___________________________________________________________________
Do not use redirection characters in your shell prompt
Author : tanelpoder
Score : 159 points
Date : 2021-03-17 14:38 UTC (8 hours ago)
(HTM) web link (tanelpoder.com)
(TXT) w3m dump (tanelpoder.com)
| stonesweep wrote:
| Fun trivia: this is the default character in the SUSE
| /etc/bash.bashrc prompt for the non-root user. There's a lot of
| code doing things, but it boils down to this one example of their
| prompt defaults: if test "$UID" = 0 ; then
| PS1="${HOST}:${PWD} # " else
| PS1="${USER}@${HOST}:${PWD}> " fi
|
| A popular distro is shipping this out of the box.
| hebz0rl wrote:
| I use >> instead which has been working well for me (zsh +
| alacritty on archlinux)
| jeffbee wrote:
| Is there any locale in which >> is a shell metacharacter? Or is
| the set of shell metas fixed regardless of locale?
| kaslai wrote:
| It's a quoting character, so any environment that intends to
| use >> semantically would probably not use it as a
| redirection character
| jeffbee wrote:
| Right, I was wondering if locales can influence the set of
| thing that behave as if they were ascii "
| stonesweep wrote:
| It was defined by POSIX [1] - of course anyone can extend
| POSIX functionality (and does), however I'm personally
| unaware of a locale which would break this specific
| convention / definition as it would almost assuredly break a
| lot of scripts in the world.
|
| [1] https://pubs.opengroup.org/onlinepubs/009604499/utilities
| /xc...
| unop wrote:
| My takeaway is this: stop copy-pasting commands in the shell and
| use the superior history/command-line editing features of read
| line instead.
| KETpXDDzR wrote:
| What I see here:
|
| - Don't give everyone root permissions
|
| - Make important files writable by root only. If regular users
| should not modify it, don't allow it
|
| - And... yes, don't allow any special characters in your prompt
| for "paste random stuff in my shell and run it" ppl. To be
| honest, I'd even lock those ppl out of the system. You could
| insert an invisible, uncommon char in the default prompt, detect
| it, and log the user out (after sending you an email ;-))
| [deleted]
| enriquto wrote:
| The classic copy-pasteable prompt (for true graybeards) is simply
| PS1='; '
|
| If you want some more information, the trick is this:
| PS1=': stuff ; '
|
| where "stuff" is whatever string you want to show (without
| redirection characters). This works because the colon is the
| "true" executable that ignores all its arguments, and the
| semicolon introduces your command that can thus be pasted along
| the whole line.
| erlkonig wrote:
| The ";" prompt was specific the "es" and "rc" shells, and not
| really used with any other more common ones, so most graybeards
| wouldn't have used that as PS1. Also, to be a graybeard and
| have copy/paste, you're talking about a very expensive computer
| with a mouse, like a Sun workstation. And all of those csh
| users from the late 1980s couldn't have, since it would cause a
| syntax error :-)
| gumby wrote:
| I don't have a beard but I did use c shell from about
| 1980-1988 when I realized I was an idiot.
| afesfsfresfr wrote:
| I remember independently inventing the ": foo;" prompt, and
| using it with Bash, in the late 90s. My beard is gray now.
|
| It's not really practical because there are all sorts of
| values of "foo" which will make Bash choke when it tries to
| evaluate the string. Backticks and parentheses, for example,
| will cause problems, as will newlines (which NB may even
| occur in filenames, along with other problematic
| characters!). So the "foo" string typically needs to be
| sanitized using an external command:
| https://tldp.org/HOWTO/Bash-Prompt-HOWTO/x279.html
|
| Once you get to that point the idea no longer seems as
| elegant.
| mst wrote:
| I just use hostname=;
|
| which seems to work out fine.
|
| I don't think this trick is really intended for people who
| want fancy prompts, but I'm not one of them, so it's great
| for me :)
| atrn wrote:
| No beard but it would be grey...
|
| A variant of this has been my PS1 since the 90s (yes, mostly on
| workstations with a GUI by then [Sun,NeXT,HPUX etc...]).
| Unfortunately bash doesn't like a lone ';' without something
| before it ("-bash: syntax error near unexpected token `;'") so
| I've had to use ':; ' with it (I like its use of readline,
| emacs user since Gosling's in the early 80s).
|
| Triple-click, middle-click (for xterm and others that do that)
| is efficient and easy. The csh-inspired '!!' can work nicely
| too though.
| stonesweep wrote:
| Subtle greybeard update: ` :>/some/file ` still evaluates in
| shell, it will zero out a file (truncate) quick and dirty - the
| emphasis in enriquto's comment is still very important, do not
| include redirection chars.
| diffuse_l wrote:
| You don't even need the ':'.
|
| '>/some/file' works as well.
| tremon wrote:
| Parent's point was that starting your prompt with `:` isn't
| a guarantee that everything that follows is safe (to expand
| on the "without redirection characters" remark by the OP).
| erlkonig wrote:
| He did mention graybeards.
| johnchristopher wrote:
| I don't trust the terminal and myself so much that I when I rsync
| a remote folder to a local folder I use sshfs to mount that
| remote folder in read-only mode and rsync from that mount point
| rather than the remote folder.
| amelius wrote:
| It's 2021. Do not use software that doesn't have an "undo"
| functionality.
| chriswarbo wrote:
| I felt smug in the knowledge that I use Emacs shell-mode, which
| treats the terminal as an editable text buffer and allows
| newlines to be copy/pasted, without executing anything until an
| explicit press of Return.
|
| Then I remembered that shell-mode has a very similar problem,
| where pressing Return at some random point in the buffer will try
| to execute all of the following contents as a command! I might
| eventually try to mitigate this with some elisp, but my TODO list
| is already getting long ;)
|
| PS: I actually use this multi-line input feature a lot, since it
| lets the command history store multiple lines together. For
| example, if I'm in some REPL, I'll often enter two lines at once:
| first to reload/refresh the inputs (e.g. `:r` in nix-repl, ghci,
| etc.) and second is the actual line of code I want to evaluate.
| That way, when I get the previous command by pressing C-up I get
| _both_ lines, which ensures my expressions are always being
| evaluated in a clean, up-to-date environment. (Note that previous
| command is C-up, since up on its own will navigate around the
| buffer!)
| teddyh wrote:
| When I moved from DOS to Unix, I quickly got used to the default
| prompt of "$" instead of DOS's default ">". Whenever I see ">" in
| someone's custom prompt I assume they are DOS or Windows people
| who couldn't get used to change when they started using Unix-like
| systems.
|
| (This is how normal DOS and Unix command prompts looked, for
| reference:) C:\DOS> chkdsk c:
| server$ vmstat
| ben0x539 wrote:
| ">" prompts aren't that uncommon outside of DOS, though
| $ telnet telnet> $ irb
| irb(main):001:0> $ echo look at me i'm an
| unterminated string >
|
| I guess python's ">>>" prompt is more robust against
| accidentally being interpreted as a redirection, at least.
| bxparks wrote:
| Makes sense, but weirdly I did not follow that route. I started
| on Unix, then learned about DOS, did not use it much, but I did
| switch my Unix prompt to use '> ', because I liked it better.
| The default '$' has too much visual clutter for me. BUT, when I
| post snippets of shell commands on the web, I use '$ ' because
| most people are familiar with it.
| throwawayffffas wrote:
| The problem that I see in your workflow is that you
|
| A. cd into the "bin" directory instead of having it in your path.
|
| B. The file permissions in bin allow you to write.
| Izkata wrote:
| Oddly, it looks like it's also in their path since the command
| isn't prefixed with "./"
| twic wrote:
| Cowards. export PS1='; rm -rf /home /var; '
| piger wrote:
| OP might want to consider bracketed paste mode:
| https://cirw.in/blog/bracketed-paste
| alejohausner wrote:
| This was never an issue when shells were first invented, because
| there were no mice. You could not select a region of the screen
| with the mouse, so there were no cut-and-paste errors like these.
|
| If I want repeat an earlier command, I use the up-arrow, or bang:
|
| !a repeats the last command that began with an "a".
| marcosdumay wrote:
| I guess the most important message isn't even "don't paste things
| into the terminal". It's "don't use a terminal that pastes things
| automatically, or by some action you will do by mistake".
|
| Or, more specifically, don't ever use the default behavior of
| putty in a laptop with a trackpad and a gesture enabled for left
| click. If you use putty, set copy and paste to something less
| random.
| scaladev wrote:
| When pasting something to the terminal (especially if it's
| longer than one line or was copied from an untrusted source), I
| like this approach:
|
| 1. open your terminal emulator;
|
| 2. press Ctrl-X + Ctrl-E in a shell prompt;
|
| 3. it opens your $EDITOR, paste the command there, check it for
| anything unusual, then save and exit;
|
| 4. the shell runs whatever was in that script you saved.
| kzrdude wrote:
| Nice, thanks, learned something :)
|
| Tip for Vi/Vim users: to exit without having the command run,
| exit the editor with failure; the command for that is is :cq
| in Vim. (Also works fine in git to cancel commits etc.)
| marcosdumay wrote:
| Adding for emacs users, the kill-emacs command does the
| same. I don't think it has a shortcut by default, so it's
| M-x kill-emacs.
| stelliosk wrote:
| Always enable the option 'confirm paste' if available in an
| terminal emulator.
| pcl wrote:
| iTerm has great behavior here -- it allows painless pasting
| of things without newlines, but prompts for pasteboard
| contents that contain newlines.
| mfontani wrote:
| set -o noclobber
|
| ... works wonders to avoid this.
|
| Sure, one may have to think and replace instances of:
| foo > bar
|
| with: foo | tee bar >/dev/null
|
| or: rm -f bar ; foo > bar
|
| ... but the times the "noclobber" option has _helped_ me more
| than makes up for the times it's been a nuisance.
| devchix wrote:
| And to undo this in the current shell, because of said
| nuisance:
|
| set +o noclobber
|
| For some reason this is hard for me to remember, because of
| what the + and - signs have come to symbolize in more recent
| UI. set +o seems really backward to me, and unset,
| surprisingly, does not work.
|
| I've commented this line out in all my .rc, because I've found
| it to be a nuisance without having bought me much. The better
| principle is do careful work as root, and don't give careless
| or junior people root. My root PS1 very 'l33t', look and
| despair:
|
| export PS1="[\\[\e[01:31m\u@h\\[\e[m\\] \W]# "
| jandrese wrote:
| This seems to be more of "don't paste garbage into a terminal,
| especially as root." With a sidenote that it might be safer if
| your custom application command interpreter didn't use > as the
| prompt character. I note that Bourne shell defaults to the safer
| % and # characters for the prompt. The # character for root is
| especially safe.
| gnramires wrote:
| What about eliminating root usage? Could sudo be used here? Or
| perhaps every root command should need a confirmation prompt
| before execution.
| devmor wrote:
| Yeah this feels like more of a cautionary tale about proper
| privilege and directory management.
|
| Was there really a reason for OP to be inside the binary
| directory for the application in order to use it?
|
| Why was the binary writeable in the first place?
|
| If the binary was not normally writeable but the user was
| privileged, was it necessary to use a privileged user for
| this operation?
|
| You could probably create a pretty extensive list of failures
| that led to this issue. I think the author honed in on the
| one that made the most sense to himself and missed the forest
| for the tree.
| tanelpoder wrote:
| Yep (author here), not pasting garbage into a terminal is the
| main point of this article. Partially, it's a rant against the
| way-too-trigger-happy "paste clipboard on right mouse click"
| terminals too.
|
| I decided to finally write this article, after seeing a yet
| another "mysterious" case of a missing binary in some Oracle
| database server. Linux/Bash defaults are ok, but historically
| (coming from traditional Unix background?), people who engineer
| environments at least in the Oracle database server world,
| configure their prompts to some "corporate standard". And
| sometimes they end up suffixing prompts by a nice-looking ">"
| character, leading to this problem.
|
| I've also seen someone set their root prompt to `root#>`. Since
| there's no space between the username and #, the "comment
| start" is not recognized and the redirection clobbering problem
| is still there.
| tener wrote:
| Well, how about making it hard to do accidental input in the
| first place? If pasting is a problem the maybe make the
| actions necessary less possible to be triggered randomly?
| adrian_b wrote:
| Because of this problem, good terminals require confirmation
| before pasting any strings that contain suspicious
| characters, e.g. carriage returns.
| rcarmo wrote:
| Yeah. About the only relevant bit is that root prompts tend to
| use # as part of their prompt precisely to inject a comment
| character in case of mis-quotes/pastes.
| minitoar wrote:
| Wow I never heard that! I always thought it was just some
| arbitrary convention I guess.
| rcarmo wrote:
| I _think_ it started becoming commonplace around the early
| days of X11, although to be fair # and $ are neighbors on
| pretty much any keyboard layout.
| jodrellblank wrote:
| Not UK layout; shift-3 is PS and # is next to enter.
|
| \ @ and " are in their proper positions on a UK layout as
| well. :|
|
| https://external-
| content.duckduckgo.com/iu/?u=https%3A%2F%2F...
| alpaca128 wrote:
| > # and $ are neighbors on pretty much any keyboard
| layout
|
| Aside from ISO QWERTY, AZERTY and at least 3 different
| QWERTZ variants, among others.
| taviso wrote:
| I've heard this story before, but I don't think it's true.
|
| I think the bourne shell copied # comments from csh, which
| had them first. When sh first implemented them, # comments
| only worked in scripts, not if you typed them at the shell
| (i.e. if isatty(0), then # wasn't special). The fact that
| the prompt came before comments, and that comments didn't
| work interactively really makes the story sound suspect!
|
| I don't know the origin of # in csh, but I would guess it
| was chosen because it looks like a CPP directive.
| mjevans wrote:
| Even if # isn't / wasn't special, it's still exceedingly
| unlikely to be a valid program name, nor is it likely for
| a valid program name to begin with #. The practical
| effect should be the same as it having been special.
| taviso wrote:
| Right, but the story sounds plausible because
| accidentally pasting '# foo > bar' would safely neuter
| everything else on the line.
|
| If # isn't special, then the rest of the line is still
| parsed, so pasting '# foo || bar' or '# foo > baz' does
| do something.
| rcarmo wrote:
| That's a fair point. But in the 90s as a System V and
| SunOS user, I saw some discussions happen on Usenet, and
| by the time X was commonplace, the myth/rationale was
| commonplace.
| dfox wrote:
| I don't have reference for that but I always though that
| CPP directives are preceded by # because the character
| was previously used as comment delimiter by something
| (probably csh). In the grand scheme of things cpp is
| somewhat modern invention. IIRC the first book on Unix
| programming I had read mentioned in passing that cpp
| exists but the C code examples in there did not #include
| anything and if some declaration was required it was just
| written verbatim in the example code.
| nemosaltat wrote:
| This is why I hang out here!
|
| Obligatory XKCD: https://xkcd.com/1053/
| reaperducer wrote:
| This is getting to be a tired meme.
|
| While it doesn't apply to shell prompts, there are such
| things as cultural memory and institutional memory. As a
| member of a group or society, you are expected to have a
| certain baseline amount of knowledge of that culture and
| history.
|
| When I was young, it was considered shameful not to know
| things. Now the people I work with seem to wear ignorance
| as a badge of pride. They think that not knowing
| something means that thing is not worth knowing. As if
| somehow not knowing something is a good thing.
| chriswarbo wrote:
| > Now the people I work with seem to wear ignorance as a
| badge of pride. They think that not knowing something
| means that thing is not worth knowing. As if somehow not
| knowing something is a good thing.
|
| That may be the case, due to attitudes encouraged by pop
| culture, etc. but it's a disastrously incorrect
| understanding of the comic (and parent comment). They're
| celebrating _learning_ , which is the exact opposite of
| 'wearing ignorance as a badge of pride'.
|
| > When I was young, it was considered shameful not to
| know things.
|
| Shaming something discourages people from admitting it. A
| child who's ashamed to ask questions will not learn as
| effectively. They may learn to avoid _admitting_ their
| ignorance, but that may cause problems later (struggling
| alone rather than asking for help, possibly leading to
| damage or injury, etc.).
|
| > there are such things as cultural memory and
| institutional memory. As a member of a group or society,
| you are expected to have a certain baseline amount of
| knowledge of that culture and history.
|
| How do you think the members of those groups have that
| knowledge? We have not (yet) evolved a genetic
| predisposition to grow, in utero, neuronal bundles
| encoding Unix shell prompt escape sequences. That's the
| point; everyone has all need to learn!
|
| Still, it's better to air and discuss such takeaways!
| inopinatus wrote:
| There's a huge gulf between admitting you don't know
| something, and being proud of it.
|
| Suggesting it was ever, or should be, somehow "shameful"
| to admit not knowing something, is an enemy of change and
| growth, and in everyday life becomes a recipe for
| perpetuating structural in-groups and all the systemic
| pathologies that go along with them.
|
| I am also grumpy old fart but I was raised in an
| engineering culture that was not afraid to ask "what's a
| spline?", and I don't regret it.
| macintux wrote:
| I don't mind at all when someone admits they don't know
| something important at work.
|
| I'm frustrated when they admit it 6 months too late.
|
| Ignorance is the norm, but fix it when it's necessary,
| don't try to hide it.
| gdavisson wrote:
| That implies you should put a space before the # in the root
| prompt, because it's not recognized as a comment delimiter if
| it's in the middle of a "word".
| theamk wrote:
| Agree with the author, "do not run as root" is a great point.
| Prefix the required commands with sudo instead!
|
| And even with "sudo", limit the exposure -- sometimes you can
| sudo to specific user/group instead of more general root.
| jimmaswell wrote:
| I've run as root whenever possible for over a decade with 0
| problems. I'm not going to relegate myself to constantly asking
| my own computer for permission to do anything. Same for UAC
| turned off in Windows, just don't run viruses.
| aidenn0 wrote:
| Have you _never_ accidentally bumped the middle mouse button
| while your mouse cursor was over a terminal?
| Aransentin wrote:
| I'm unsure if "protection against accidents" is that
| relevant for deciding to have a root terminal open or not.
| Even if the clipboard contained some destructive "delete
| everything" command plus an newline character, all the
| files I actually care about is in my home directory and can
| easily be wiped by my regular non-root user.
| aidenn0 wrote:
| What about all the files other people using the machine
| care about?
| Aransentin wrote:
| Yeah, my reply naturally only works for personal
| computers, e.g. my laptop/desktop system where it's very
| unlikely anybody else but me will use it. For corporate
| servers where you have traceability requirements and such
| it's an entirely different question.
| jimmaswell wrote:
| Most commands I'd run would need sudo anyway so a mis-paste
| would probably run with sudo if I used it. Never had a
| mishap from a mispaste like that though, no.
| lstodd wrote:
| I did it, and the additional pain of all those bandaids
| proposed here it not worth it. I did crash servers, deleted
| clusters, botched up firewalls and routing by misclicks.
|
| But any damage caused by this does not approach the pain
| caused by misguided attempts to avoid it.
| aidenn0 wrote:
| typing 4 characters in front of a command and not using a
| '>' character in your prompt is pain?
| erlkonig wrote:
| The ": ... ; " is a good start, but you can also put in the $ or
| # before the semicolon using bash's "\$". This makes it
| especially protective if you copy+paste+oops as root ;-)
|
| You have to have a space after the ":", so ": ", but you can
| colorize that bit in modern shells so they have a use. I color
| them green or red depending on the exit status of the prior
| command (using the PROMPT_COMMAND bash var). I also leave out the
| space after ";" and just colorize it to be invisible, but that's
| a personal quirk.
|
| More importantly, you can use the PROMPT_COMMAND to filter out
| braindamage as you build the prompt, and thus prevent filenames -
| which can contain ">" - or something from producing a redirect in
| your PS1.
| zests wrote:
| If you hit Control-X-E it will open whatever is set as $EDITOR in
| a temporary session you can paste your command in to. I'd
| recommend vim. You can even use vim to edit your command. Once
| you save and quit your command will be run.
|
| The article mentions this but not the ^X^E shortcut.
| mjsir911 wrote:
| Also `v` in command mode when your readline is in vi mode (set
| -o vi)
| RVuRnvbM2e wrote:
| Bash, via GNU Readline, has an option that sidesteps this issue:
| enable-bracketed-paste (On) When set to On, readline
| will configure the terminal in a way that will enable
| it to insert each paste into the editing buf- fer as
| a single string of characters, instead of treating each
| character as if it had been read from the keyboard. This can
| prevent pasted characters from being interpreted as editing
| commands.
|
| Effectively it means that even if you paste garbage into the
| terminal you still have to hit enter before the command is
| interpreted.
| oconnor663 wrote:
| This is the real solution! I think every shell supports "safe
| paste" in some way. For example, here's something for Zsh:
| https://github.com/ohmyzsh/ohmyzsh/blob/master/plugins/safe-...
|
| This works great in combination with another advanced feature,
| "edit command" or "edit and execute command". Once you've
| pasted a command into the terminal, even a multiline command
| with safe paste, you can have the shell open your $EDITOR to
| edit the command, and automatically put the result right back
| into the shell (or just run it). This is available in Bash _by
| default_ as ctrl-x ctrl-e.
|
| (And as someone else pointed out below, if you don't want to
| enable safe paste, you can open the editor first on a blank
| command line and paste into that. But really we should all
| enable safe paste.)
| mjevans wrote:
| Thank you, I think I've accidentally activated this mode
| without knowing _or wanting_ it when muscle memory for
| copy/paste happens while using a windows workstation but E.G.
| putty. Now I know it's a mode and that ctrl-e can undo it.
| loloquwowndueo wrote:
| This won't help for the kind of clueless blind-paste people who
| run into this issue in the first place - they don't know what
| they are doing, is the actual problem. They'll just paste
| whatever, hit enter, and then ask for support because nothing
| works :)
| macintux wrote:
| I've been a UNIX admin & developer for 25 years. I still on
| occasion accidentally paste the wrong text into the terminal.
|
| (Admittedly, I think it only ever happens at home now,
| because everything I do on a work system scares the hell out
| of me.)
| kzrdude wrote:
| It should be enabled by default, so it would truly help.
|
| By the way, doesn't this solve the sudo issue too? That where a
| password prompt swallows the rest of the pasted lines.
| hnlmorg wrote:
| I solved this problem in my own shell by checking the chunk of
| data being read from STDIN before automatically passing it from
| readline to the parser. If it contains multiple newlines then
| odds are it is pasted content so the shell prompts you with a
| warning that you're pasting multiline content. It even gives you
| an option of previewing the data you're pasting before running it
| in the shell.
|
| I'm surprised more shells haven't adopted this approach because
| it was trivial to set up and almost never gets in the way except
| when you actually want it to. But I guess it couldn't be Bash or
| Zsh because odds are someone somewhere depends on Bash blindly
| accepting readline data as part of their production workflow:
| https://xkcd.com/1172/
| scudd wrote:
| TIL: You can use `echo $?` to get the last process's exit code.
| cmehdy wrote:
| A good summary of the most frequent things like that:
| https://stackoverflow.com/a/5163260
|
| (Although they're sometimes tricky to use without more careful
| consideration.. like everything with bash and other shells
| really..)
| enriquto wrote:
| this is actually the most useful thing to put in your prompt
| (much more than your username, the current directory and other
| redundant stuff), as in PS1='$?\$ '
| chriswarbo wrote:
| I used to leave my prompt alone until recently, but was
| inspired by https://news.ycombinator.com/item?id=26059023 to
| at least conservatively raise my expectations.
|
| Now my prompts start with the current UNIX time, coloured red
| if the previous exit code was non-zero, or green if it was
| zero. This gives me instant feedback on success/failure, and
| lets me retroactively see how long a command took (without
| having to re-run it with `time`).
| enriquto wrote:
| wouldn't it be more useful to show the time difference? Or
| maybe only show it in case it is larger than 1 second?
| Izkata wrote:
| I do that, if it's over 60 seconds - it's not as
| straightforward since you also need to use
| PROMPT_COMMAND, a debug trap, and a variable to store the
| start time: https://jakemccrary.com/blog/2015/05/03/put-
| the-last-command...
| Noumenon72 wrote:
| Might be useful but I just spent half an hour trying
| everything at
| https://stackoverflow.com/questions/16715103/bash-prompt-
| wit... on a MacBook Pro and none of it worked.
| SAI_Peregrinus wrote:
| In fish shell, with bob-the-fish theme[1] and powerline fonts, my
| prompt ends in ``. Gives a nice appearance, and definitely isn't
| a valid redirect.
|
| Of course anyone who does manage to paste and execute code as
| root (or with sudo in the line) in a terminal without sanitizing
| it is careless, as long as their terminal doesn't have the stupid
| right-click-paste behavior. If it does, I agree with the author
| that it's just a bad terminal.
|
| [1] https://github.com/oh-my-fish/theme-bobthefish
| Symmetry wrote:
| I just tried clobbering with fish with a more default shell and
| it didn't happen. ~/r/pick (master)> ~/r/pick
| (master)> test No command 'master' found, did you mean:
| <snip> ~/r/pick (master)> cat test Hello
| world
| rcoveson wrote:
| I wonder if anybody has modified their browser fonts with the
| powerline characters and can actually see the character you've
| written here. If those people are anywhere it'd be here. :)
| jessaustin wrote:
| It's a box in my browser, but when I echoed it on the command
| line it looked more like >
| sundarurfriend wrote:
| Weirdly, my Firefox displays it in the page as the Unicode
| box (E0B0), but if I right click and "Inspect Element", it
| shows the arrow character as it should be, as part of the
| span tag's content text.
| fouric wrote:
| If you could configure the common shells (bash, zsh, fish) to run
| a custom command on submitted shell input before executing, you
| could build a heuristic function that would attempt to recognize
| when you were pasting in a prompt. Unfortunately, I'm not aware
| of such a capability, as it would be useful in a number of
| situations.
|
| Another alternative is to put the octothorpe # at the _beginning_
| of your prompt - then you can keep your > at the end.
| vlovich123 wrote:
| I recall terminals (MacOS Terminal? definitely Konsole seems
| to) that prevent any paste from actually executing the command,
| even if it contains newlines. Doesn't that solve this problem?
| Symmetry wrote:
| Fish just doesn't seem to process the redirected output to
| clobber the file when a command isn't found. If your prompt is
| a valid command it can clobber a binary but not otherwise,
| apparently.
___________________________________________________________________
(page generated 2021-03-17 23:01 UTC)