From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28141 invoked by alias); 7 Nov 2015 06:38:06 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 20909 Received: (qmail 7850 invoked from network); 7 Nov 2015 06:38:05 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8MpeU4VZ3ANiZGxRJIhDrRDgh0tcZuaDjnaospbWPcE=; b=FO8E3dHp33IBorhmUYYrdQgx+uRtrorQAfV4x9/I98G39lJjxlGCoL+fUrnAWTM6/u PBx5NHcBExxCAUy4Rg1uL/tUlAq8J+EvwAavL/naVoQgdpLNLm2+8VObz0stXO7/S82T TcafwfvzJv5toqqRmdZbsh9nssqFMpk1dzRLk3i3nbisj3vEuh4TANeTfe7tlDePu2gt zalDLSWzjJ5LrTjN1N4fQTsNsFTKBr61OJFzP1DF2vqs07QJkXQvmB3JFXlJ7O4C2dyL UHssjkFiWJ6RC6q9qg48L/s99atRpDh6fkSXSLJaKqlWsdIP/FkYMMfT0Ltebi0/TWI9 ez3A== MIME-Version: 1.0 X-Received: by 10.140.151.129 with SMTP id 123mr18293990qhx.79.1446878283533; Fri, 06 Nov 2015 22:38:03 -0800 (PST) In-Reply-To: <563D974B.3000308@eastlink.ca> References: <563D5ED5.1070102@eastlink.ca> <563D974B.3000308@eastlink.ca> Date: Sat, 7 Nov 2015 07:38:03 +0100 Message-ID: Subject: Re: convolutions From: Mikael Magnusson To: Ray Andrews Cc: Zsh Users Content-Type: text/plain; charset=UTF-8 On Sat, Nov 7, 2015 at 7:16 AM, Ray Andrews wrote: > On 11/06/2015 09:37 PM, Mikael Magnusson wrote: >> >> A smart thing to include when asking for a simpler way to do an obfuscated >> thing is what it is you're actually trying to do. Saves people the effort of >> trying to deobfuscate your code first. It's also super unclear what you mean >> by "expanding $red into native". > > > ... expanding color variables, eg. " ${red} " into their native " \e[31;1m " > in a file. > > That isn't clear? No, because 'expanding into "\e"' means nothing useful, did you mean a literal backslash followed by an e, or a literal escape? > Variables holding color codes seem like a very routine > thing to me, there are many of them as a standard part of the shell. If you > have some long string with color variables ( eg. "$_red" ) in it, and you > echo the string, the colors execute, but if you save that same string to a > file and 'cat' it, the color variables do not expand If you store the string in a parameter and echo that parameter, the color variables also don't expand. >--it is necessary to > convert them to the actual escape codes. My code snippet does that, I'm just > wondering if it's as simple as it can be. If you have a parameter with \e in it, and want to expand it to a literal escape byte, the easiest way is to use ${(g::)red}. So you have a file with "${red}" in it, and you want to read in the file, and substitute the value of any parameter references. Moreover, these parameters are not defined in the file, but are set in the shell environment and you happen to know that they are string representations of color escape sequences, and you want to expand these as well. Perhaps you should take a step back and redesign whatever it is you're doing, because it really doesn't seem like a good way to handle things :). If your file has a semicolon in it somewhere, then your command will run arbitrary code. Bart's example doesn't have that exact problem, but will still execute code if there are things like $(command) in the file. -- Mikael Magnusson