I have a minor problem with viewing one variable in a table. I changed data type of "date" from object to datetime64, but now it is displayed on 2 lines.
This is the code I used.
df['date']=pd.to_datetime(df["date"])
Is there a way to make it work on one line?
I tried to widen the "date" column, by setting up the maximum width.
pd.set_option('max_colwidth', None)
I think you are asking why the dash breaks the line. In order to force a non-breaking hyphen, replace the normal "-" with this HTML entity:
‑
That is also displayed as a hyphen, but it will not cause a line break.
Related
I'm trying to come up with a regex for enforcing Git commit messages to match a certain format. I've been banging my head against the keyboard modifying the semi-working version I have, but I just can't get it to work exactly as I want. Here's what I have now:
/^([a-z]{2,4}-[\d]{2,5}[, \n]{1,2})+\n{1}^[\w\n\s\*\-\.\:\'\,]+/i
Here's the text I'm trying to enforce:
AB-1432, ABC-435, ABCD-42
Here is the multiline description, following a blank
line after the Jira issue IDs
- Maybe bullet points, with either dashes
* Or asterisks
Currently, it matches that, but it will also match if there's no blank line after the issue IDs, and if there's multiple blank lines after.
Is there anyway to enforce that, or will I just have to live with it?
It's also pretty ugly, I'm sure there's a more succinct way to write that out.
Thanks.
Your regex allows for \n as one of the possible characters after the required newline, so that's why it matches when there are multiple.
Here's a cleaned up regex:
/^([a-z]{2,4}-\d{2,5}(?=[, \n]),? ?\n?)+^\n([-\w\s*.:',]+\n)+/i
Notes:
This requires at least one [-\w\s*.:',] character before the next newline.
I changed the issue IDs to have one possible comma, space, and newline, in that order (up to one of each). Can you use lookaheads? If so, I added (?=[, \n]) to make sure the issue ID is followed by at least one of those characters.
Also notice that many of the characters don't need to be escaped in a character class.
In a bash script, I'm looking for a way to display a text field (probably surrounded by asterisks or something) that is 72 columns wide that the user can type in. I would like to run the script, and at one point set the value of a variable to what this text field returns, newlines included. They would exit text entry with some key sequence or a line with one word, the sentinal value, followed by the enter key. Upon exciting, the variable contains the text, including newlines.
I currently can capture the text using $(cat) or a simple read loop, but I'm looking for an an alternative, or a way to restrict lines to 72 and keep newlines using those methods.
Any ideas?
I ended up going with dialog using the --editbox option after creating a temporary text file. Thank you for the suggestions – broma0
I have a link in an apex report which takes the user to different page, and it passes some values to the new page. The button is set to a url because there are too many items being passed, but I don't think that would matter anyway:
f?p=&APP_ID.:27:&SESSION.::&DEBUG.::P27_1,P27_2,P27_3,P27_4,P27_5:0,#1#,#2#,#3#,#NULL#
The #1#, etc. are columns being passed. Everything seems to work correctly except that the data being passed often contains a colon (:), which messes up Apex's built in colon structure by cutting off anything in the new page's item that happens after the colon (including the colon itself) as well as messing up any fields after that. For example: #2# has a colon in it, so P27_3, 4, and 5 will not be filled with values.
I've tried manually replacing the colon with a '%3a' (the url encoding for colon), but it doesn't seem to work.
Try using UTL_URL.ESCAPE() to escape URL special characters and UTL_URL.UNESCAPE() to un-escape them back.
You can also try APEX_UTIL.URL_ENCODE() but you need to use one or the other, i.e. either UTL or APEX_UTIL.
I'm using VB6 and ADO together with the Microsoft Text Driver to import data from an ASCII file. The file is comma delimited but it also contains double quotation marks around text data fields. The fields are also fixed width.
I'm having a problem that the driver reads the columns incorrectly any time one of the rows contains a quotation mark double quotation inside the content. This happens inside the "part description" column which is the second column from the left. When this occurs, columns to the right are all Null value, which is not the case in the text file.
I think it would be better to use only the commas as delimiters. However, I believe that commas also occur in the "part description" column so this means I should really load the file as fixed width. I'm not aware that there is any way of doing this unless I can specify this in the schema.ini file.
Any ideas on how to resolve this?
Edit:
You are allowed to specify fixed width in your Schema.ini file. However, it appears to me that the commas and quotation marks that also exist as delimiters/qualifiers will prevent this from working properly. It looks like I may have to "manually" read the file in and write it back out in my own format before I load it using the MS Text driver. Still looking for other opinions.
I would try changing the Format value in the registry for the Jet text engine (if that's what you're using) at the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines\Text. I think the default is CSVDelimited but you would change this to FixedLength. See http://msdn.microsoft.com/en-us/library/ms974559.aspx
It's probably worth adding that although you have a Schema.ini file for settings, on some options the registry overrules them anyway
Actually, looking at the link I supplied, it seems you have to use a schema.ini file for fixed-length files. Have you tried something like the following, which specifies the width?
[Test.txt]
Format=FixedLength
Col1=FirstName Text Width 7
Col2=LastName Text Width 10
Col3=ID Text Integer 3
I'm extra precautious with regional settings -- some users change default list separator. Usualy fix this with schema.ini like this:
[MyFile.csv]
Format=Delimited(,)
I've written a more detailed post about this on my blog at:
http://idisposable.co.uk/2010/07/chrome-are-you-sanitising-my-inputs-without-my-permission/
but basically, I have a string which is:
||abcdefg
hijklmn
opqrstu
vwxyz
||
the pipes I've added to give an indiciation of where the string starts and ends, in particular note the final carriage return on the last line.
I need to put this into a hidden form variable to post off to a supplier.
In basically, any browser except chrome, I get the following:
<input type="hidden" id="pareqMsg" value="abcdefg
hijklmn
opqrstu
vwxyz
" />
but in chrome, it seems to apply a .Trim() or something else that gives me:
<input type="hidden" id="pareqMsg" value="abcdefg
hijklmn
opqrstu
vwxyz" />
Notice it's cut off the last carriage return. These carriage returns (when Encoded) come up as %0A if that helps.
Basically, in any browser except chrome, the whole thing just works and I get the desired response from the third party. In Chrome, I get an 'invalid pareq' message (which suggests to me that those last carriage returns are important to the supplier).
Chrome version is 5.0.375.99
Am I going mad, or is this a bug?
Cheers,
Terry
You can't rely on form submission to preserve the exact character data you include in the value of a hidden field. I've had issues in the past with Firefox converting CRLF (\r\n) sequences into bare LFs, and your experience shows that Chrome's behaviour is similarly confusing.
And it turns out, it's not really a bug.
Remember that what you're supplying here is an HTML attribute value - strictly, the HTML 4 DTD defines the value attribute of the <input> element as of type CDATA. The HTML spec has this to say about CDATA attribute values:
User agents should interpret attribute values as follows:
Replace character entities with characters,
Ignore line feeds,
Replace each carriage return or tab with a single space.
User agents may ignore leading and trailing white space in CDATA attribute values (e.g., " myval " may be interpreted as "myval"). Authors should not declare attribute values with leading or trailing white space.
So whitespace within the attribute value is subject to a number of user agent transformations - conforming browsers should apparently be discarding all your linefeeds, not only the trailing one - so Chrome's behaviour is indeed buggy, but in the opposite direction to the one you want.
However, note that the browser is also expected to replace character entities with characters - which suggests you ought to be able to encode your CRs and LFs as
and
, and even spaces as , eliminating any actual whitespace characters from your value field altogether.
However, browser compliance with these SGML parsing rules is, as you've found, patchy, so your mileage may certainly vary.
Confirmed it here. It trims trailing CRLFs, they don't get parsed into the browser's DOM (I assume for all HTML attributes).
If you append CRLF with script, e.g.
var pareqMsg = document.forms[0]['pareqMsg']
if (/\r\n$/.test(pareqMsg.value) == false)
pareqMsg.value += '\r\n';
...they do get maintained and POSTed back to the server. Although the hidden <textarea> idea suggested by Gaby might be easier!
Normally in an input box you cannot enter (by keyboard) a newline.. so perhaps chrome enforces this even for embedded, through the attributes, values ..
try using a textarea (with display:none)..